Jim Fulton wrote: >> Sometimes it feels to me that when Stephan or you prioritize a bug that >> you have a rough understanding of the solution, > > You are mistaken. Stephan should speak up on his criteria, but I have > the impression that it is "guilty until proven innocent". That is, I > think he marks everything new as critical and relies on people working > on bugs to downgrade them.
Ah. That's different than what I expected! But I'm alright with it once I know it. I totally agree that the process might not be as complex as I imply, but the thing is that there are places where I *feel* like I'm missing something. And hidden parts of a process make it seem to be complex. At least for me. And for some reason, I don't manage to jump into the right mode everytime and ask for process clarification immediately. > For myself, I consider the effect of the bug, not the solution. If I > have an idea what the solution is, I either note it or assign it to myself. Ok, good to know then. >>>>> 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? >>> >>> Yes. I think it is a shame to have to do this, but I think this is now >>> necessary. >>> >>> I would go further. I would not unfreeze the trunk until until we've >>> cleaned up all open bugs, either by fixing them or rejecting them. >> >> See my statement on our bug history. This might be a large but very cool >> one-time effort to get our history cleaned up. We could have one large >> release that is targeted at getting rid of all open bugs. Maybe we >> should do this for 3.4 and put eggification to 3.5? > > Or maybe it should be a 3.3.x release and we don't allow any more > feature work until the collector is cleaned out. We're actually not > that far from that as we did make a lot of progress during this last cycle. > > I do think we should schedule 3.4 for May, not November. > > And I think we need to start the beta cycle earlier. I think the beta > cycle for a May release should start March 1. I really think we're > already too late to make a November release. > >> I really can imaging having more gocept developers fixing a bug here and >> there if we do that. Weird motivation, but it's easier to communicate. > > Cool, get them started now. We don't have to wait until November to get > a 3,3,1 release that includes resolution of all the old bugs. Scheduling some effort for a nice 3.3.1 is more reasonable. Then I'd be fine with a post-poned 3.4. >>> If we're going ti do time-based releases, we need to have a realistic >>> schedule and the necessary commitment to meet that schedule. Right now, >>> we have neither. >> >> Ack. We didn't even have a road map written down nor a set of features >> we committed on. >> >> I'm trying to summarize some of the ideas and open ends from my posting: >> >> - What about having a list of all (semi-)active committers so we can >> ping them and ask for their assistance? > > Um, there's something wrong with this. So the more someone contributes, > the more they'll be asked to contribute more? > > Anyway, I have a script that I used to determine foundation committer > nominees. I'd be happy to share this with anyone who wants to nag people > who already contribute a lot to ask them to contribute more. That's not exactly what I meant. How many people are actually contributing? I'd like to know if we're talking about 5, 10 or 20 people. >> - What about making the point in Zope 3.4 about fixing up our bug >> history? > > Isn't that what bug-fix releases are for? Why not make that the goal of > 3.3.1? Or better yet, let's make this time based! Let's say that all > of the bugs in the collector reported as of the final release have to be > fixed in 3.3.1 one month after the final release. Well. Almost. My point was to make a small 3.4 release which could already integrate the features we made on the trunk, so that we don't get a hunormous release in May. However, as I get another side effect from this (later deprecation), I'm fine with some effort one 3.3.1. >> - I think we want a release manager. > > You're a genius! I'll just snap my fingers. What happened after you snapped? :) Does the application of irony indicate that we (I) should get over it and ignore the problem (for now)? Do we want to find a way how to go without a release manager? I don't like agreeing that there is an open end and than just letting the discussion about it die somewhere. I just wanted to be explicit. >> - Make it easier (or make it better understood how) to make releases. > > +1 MakingARelease spells it out pretty clearly. There are a lot of > issues here that I don't want to bring into this thread. New thread then? 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
