| | 8 | == Agenda == |
| | 9 | |
| | 10 | * Purpose |
| | 11 | * Agree on practices and policies that we can carry out |
| | 12 | * clarity avoids ambiguity and potential conflict |
| | 13 | * new and existing users can know what to expect |
| | 14 | * baseline for discussions about making changes |
| | 15 | * Discuss ways to broaden the developer base for Buildbot |
| | 16 | * lots of contributors (yay!), relatively few maintainers |
| | 17 | * limited capacity for work on big projects |
| | 18 | * project direction follows maintainer's interests |
| | 19 | * bus factor |
| | 20 | * do we somehow block potential maintainers? |
| | 21 | * how can we better recognize contributions? |
| | 22 | * can we establish intermediate roles for devs? |
| | 23 | * 0.8.3 news |
| 9 | | * defined dev roles |
| 10 | | * developer permissions (e.g., trac admin, commit) |
| | 25 | * define components (see tags/keywords) |
| | 26 | * developer roles |
| | 27 | * core maintainer, component maintainer, tester, packager, infrastructure, security |
| | 28 | * developer permissions |
| | 29 | * commit, root, trac admin, IRC +v |
| 12 | | * GSoC? |
| 13 | | * Development Policies |
| 14 | | * incident response |
| 15 | | * dependency version requirements |
| 16 | | * Releases |
| 17 | | * release pace |
| 18 | | * support calendar for old versions |
| 19 | | * release process (rc's? betas?) |
| 20 | | * downstream communication (e.g., linux distros, macports, opencsw) |
| 21 | | * Licensing |
| 22 | | * can we put new components under less restrictive licenses? |
| | 31 | * how does a contributor know when to ask for commit rights? |
| | 32 | * Google Summer of Code? |
| | 33 | * needs someone to drive it |
| | 34 | * Policies |
| | 35 | * security incident response |
| | 36 | * team membership |
| | 37 | * version requirements for dependencies |
| | 38 | * Python, Twisted, Jinja, SQLAlchemy, etc. |
| | 39 | * review |
| | 40 | * licensing |
| | 41 | * stuck with GPLv2; can we make new components? |
| | 42 | * Release Policies |
| | 43 | * release pace/timing (current: every 2-3mo) |
| | 44 | * support (fixes) for old versions (any? how long?) |
| | 45 | * release process changes |
| | 46 | * currently rc's for packagers, then full release |
| | 47 | * downstream communication |
| | 48 | * better communication with packagers? |
| 24 | | * boilerplate "about Buildbot" needs work |
| 25 | | * consistent web design for all buildbot pages |
| 26 | | * Out of process status serving |
| 27 | | * statusdb |
| 28 | | * statuspush |
| | 50 | * boilerplate "about Buildbot" text needs work |
| | 51 | * consistent visual design for docs, Metabuildbot, Trac |
| | 52 | * Technical Futurey Stuff! |
| | 53 | * 0.9.0: out of process status serving |
| | 54 | * statusdb (history) |
| | 55 | * statuspush (events) |
| | 56 | * 0.10.0: buildbot as a framework |
| | 57 | * well-defined subclassing APIs |
| | 58 | * test harnesses for custom classes |
| | 59 | * message broker structure |
| | 60 | * dynamic reconfig via graceful restart |
| | 61 | * simplified slaves |