Changes between Initial Version and Version 1 of Meeting17December2010


Ignore:
Timestamp:
Dec 18, 2010, 3:41:49 AM (8 years ago)
Author:
dustin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Meeting17December2010

    v1 v1  
     1This was primarily an organizational summit, although technical topics are certainly welcome as well.
     2
     3== Agenda ==
     4
     5 * Purpose
     6  * Agree on practices and policies that we can carry out
     7   * clarity avoids ambiguity and potential conflict
     8   * new and existing users can know what to expect
     9   * baseline for discussions about making changes
     10  * Discuss ways to broaden the developer base for Buildbot
     11   * lots of contributors (yay!), relatively few maintainers
     12   * limited capacity for work on big projects
     13   * project direction follows maintainer's interests
     14   * bus factor
     15  * do we somehow block potential maintainers?
     16   * how can we better recognize contributions?
     17  * can we establish intermediate roles for devs?
     18 * 0.8.3 news
     19 * Developer Recruitment
     20  * define components (see tags/keywords)
     21   * In VC; jettison unmaintained, buggy components
     22  * developer roles
     23   * core maintainer, component maintainer, tester, packager, infrastructure, security
     24  * developer permissions
     25   * commit, root, trac admin, IRC +v
     26  * promotion process
     27   * how does a contributor know when to ask for commit rights?
     28  * Google Summer of Code?
     29   * needs someone to drive it
     30 * Policies
     31  * security incident response
     32   * team membership
     33  * version requirements for dependencies
     34   * Python, Twisted, Jinja, SQLAlchemy, etc.
     35  * review
     36  * licensing
     37   * stuck with GPLv2; can we make new components?
     38 * Release Policies
     39  * release pace/timing (current: every 2-3mo)
     40  * support (fixes) for old versions (any? how long?)
     41  * release process changes
     42   * currently rc's for packagers, then full release
     43  * downstream communication
     44   * better communication with packagers?
     45 * Brand upgrade
     46  * boilerplate "about Buildbot" text needs work
     47  * consistent visual design for docs, Metabuildbot, Trac
     48 * Technical Futurey Stuff!
     49  * 0.9.0: out of process status serving
     50   * statusdb (history)
     51   * statuspush (events)
     52  * 0.10.0: buildbot as a framework
     53   * well-defined subclassing APIs
     54   * test harnesses for custom classes
     55   * message broker structure
     56   * dynamic reconfig via graceful restart
     57   * simplified slaves
     58
     59== Dustin's Notes ==
     60
     61These are Dustin's notes from the meeting
     62
     63 * components
     64  * assign maintainers to components, and track it officially in git
     65  * need a loose definition of "maintainer" that can include "concerned user" as a domain expert
     66  * another option: if you like $component, offer a slave to test it.  This is especially relevant for version control
     67 * commit rights and other developer permissions
     68  * I should offer, rather than wait for developers to ask -- push instead of waiting
     69 * for security: committers *are* the response team
     70  * use a private github repository, where we can track issues
     71  * write reporting guidelines for those who discover a vulnerability (email an alias)
     72  * write down the response process - who to email, what to patch, etc.
     73  * continue to operate in firefighting mode for now, rather than trying to take a comprehensive approach without comprehensive APIs
     74 * Dependency versions
     75  * versions are much more of a worry for buildslaves, rather than masters, so the policy approach should be different
     76  * python version compatibility is different from prerequisite packages (which can be installed easily if necessary)
     77  * at a minimum, we should support prerequisite versions shipped with the most recent distro
     78  * when bumping a requirement, name the feature necessary, and if possible allow older versions of the prerequisite for configs not using that feature
     79 * Licensing
     80  * Licensing the JS UI separately would help Apple and others both use and contribute to the project, so it's a win
     81 * Support for old versions (LTS)
     82  * in general, we should only support the most recent version, except for security patches
     83  * we got a number of users stuck on 0.7.{10,11,12} during the 0.8.0 transition.  Why?
     84   * x.0 is scary -- let it settle down first
     85   * performance was a worry with a database backend
     86   * observed breakage in new versions, so upgrading was a bigger project
     87   * 0.8.0 didn't introduce features, so there was no drive to upgrade
     88  * takeaways:
     89   * plan ahead for major upgrades - do a stability release of e.g., 0.8.last before starting 0.9.1
     90   * do not add major features in 0.x.0, so that early adopters can shake out bugs first
     91 * Version numbering: drop the leading 0 in 0.10, so we'll have 0.8.x, 0.9.x, then 10.x
     92
     93=== Roundtable ===
     94 * Log/artifact Storage
     95  * separate log server?
     96   * push logs (artifacts) to it directly from slave
     97   * use a unique identifier (hash?) for the artifact; perhaps pre-generate that unique id before getting the data, if that makes coordination easier
     98  * tailing is cool, but should be treated as a special case, as the important thing is getting the artifacts where they need to be
     99  * we have lots of models for how data should move: to central server? between two slaves? into a cluster of servers?
     100  * ddunbar is interested in working on / driving this
     101 * Separate server processes are helpful, but can't be required
     102  * for performance monitoring - "oh, the scheduler process is pegged"
     103  * for distribution - "my artifact server deals with a lot of data, so I moved it off to chunky hardware"
     104 * Supporting "Easy" configurations
     105  * sample config should work - and does now
     106  * Hosted config generator??
     107    * loki does a good job here
     108  * Making the slave list dynamically editable
     109    * makes it easy to add/remove a user-submitted slave at runtime
     110    * this is a smaller case of web-based config editor
     111    * do we really need slave "names"?  Can a slave just connect to the master and say "I can do builds"?  (Its identity would be in the build history for debugging purposes)