Hi, Jim Fulton wrote: > > On Sep 12, 2006, at 8:58 AM, Christian Theune wrote: > ... >> Ack. One thing that bothers me (and it's totally possible that I'm >> missing some documentation from zope.org) is that the overall process >> isn't well documented, so it's hard for me (and probably other people) >> to jump in and do stuff. > > Um. I'm sure that it could be clearer, but how complicated is it really? > You fix the bug on the release branch, including updating CHANGES,txt, > merge the change to the trunk, and resolve the issue.
I was more referring to the selection of bugs, figuring out what release is immanent, what the repository status is, ... >> Right now I *feel* like only Stephan and Jim know how to triage bugs and >> that I'll do something that won't be right. > > Huh? There's no magic or special expertise involved. Obviously no magic, but not needing special expertise is something you can't derive by looking at what you do. Especially as priorities are set without a comment. And I think you do apply reasoning, and everybody reasons a bit different (also widely the same too). >> I probably could just go >> forward, but I have a bad feeling about my knowledge about the process, >> and I don't want to feel bad, so I don't do it. (Which makes me feel >> just slightly bad because I didn't do anything. ;) ) > > I think you are making this harder than it really is. I've been training a long time to make things as hard as possible. > FWIW, I use the following approach: > > - Early in the process, I mark every real reproducable bug as blocking. > In this last go around, this included a number of bugs that had been > around for months or years. > > - Later in the process I downgraded lots of bugs because I didn't want to > block the release. > > If people report bugs during beta testing, I think it's important to > resolve > the bugs reported, otherwise, why should people bother testing. If > people aren't going to test, then why have beta releases. Why should > anyone use Zope if we don't bother testing it. > > ... Alright. That's good for me to know. I can judge bugs based on that. I just need that one tiny explicit piece on what to apply. To almost quote David Allan: When people want to do work, they shouldn't have to go to the 'thinking about how to do work'-mode because that will put them in a state of uncertainty which disallows any actions. >>>> 2. Feature freeze the trunk until the previous release has made it to >>>> release candidate status >>> >>> You mean don't branch the trunk (and thus let it be the release branch) >>> until the release has made it to release candidate status? >>> >>> +1. Keep things focused on the release during the release cycle is >>> useful. >> >> Right. In addition to that, I'd love to have a single "status" page (a >> bit like Mozilla has) that says: >> >> - Zope 3.2 is in maintenance mode, please make sure bugs are ported >> to this release. >> - Zope 3.3 is in release mode (beta). >> Please fix bugs until XXX. No features allowed. >> - The trunk is frozen. >> >> (Or whatever information is appropriate at a given point in time) > > Sounds great. I'm sure one of our copious volunteers will make it happen. I know. :( *sigh. I know I can't step forward. I wonder if there is a way to implement a community effort to avoid having to have some individual to commit to a maintenance task? Otherwise anything we come up with that requires maintenance will be a no-go. >> +100 for the button. (A huge wiki page on how to do a release does *not* >> account for a button) > > I can't think of a civil response to this, so I'll just hold my tongue. :( Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com