On 8/4/2010 12:42 PM, exar...@twistedmatrix.com wrote: > On 03:31 pm, ba...@python.org wrote: >> On Aug 04, 2010, at 03:15 PM, exar...@twistedmatrix.com wrote: >>> On 02:51 pm, ba...@python.org wrote: >>>> On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote: >>>>> I think the issue is that many core developers don't have the reflex >>>>> to check buildbot state after they commit some changes (or at least >>>>> on a regular, say weekly, basis), and so gradually the buildbots have >>>>> a tendency to turn from green to red, one after another. >>>> >>>> I'd classify this as a failure of the tools, not of the developers. >>>>> These post-commit verification steps should be proactive, and scream >>>>> really >loud (or >>>> even prevent future commits) until everything is green again. >>>>> Buildbots themselves can be unstable, so this may or may not be >>>>> workable, and >changing >>>> any of this will take valuable volunteer time. It's also unsexy work. >>> >>> How hard is it to look at a web page? >> >> That's not the right question :) >> >> The real questions are: how hard is it to remember how to find the >> appropriate >> web page > > Oh, come on. I don't believe this. >> how hard is it to know which buildbots are *actually* stable enough >> to rely on, > > This is more plausible. But it's not the tools' fault that the test > suite has intermittent failures. Developers choose to add new features > or change existing ones instead of fixing bugs in existing code or > tests. I'd call that a developer failure. >> how hard is it to decipher the results to know what they're >> telling you? > > Red bad, green good. > > A much more plausible explanation, to me, is that most developers don't > really care if things are completely working most of the time. They're > happy to push the work onto other developers and onto the release team. > And as long as other developers let them get away with that, it's not > likely to stop. > > But perhaps the people picking up the slack here don't mind and are > happy to keep doing it, in which case nothing needs to change.
This whole discussion seems to make it clear that the release manager procedures are still ill-defined in certain areas. Otherwise a release manager could proceed by reading a web page an even, heaven help us, following specific links to ensure particular actions were taken. But I see rules being established ("there's a language moratorium: no changes!", "no release should be made unless the buildbots are *all* green") and then ignored apparently on a whim. This doesn't give people any confidence that the rules actually mean much, and I think ignoring the latter rule can negatively affect quality. Establishing comprehensive procedures can be as difficult as programming, though, and requires skills that have eluded me through a fairly lengthy technical career. So it also boils down to shortage of manpower of a particular kind. People with programming skill would, understandably, rather invest their time in something they are good at. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com