Re: [Zope3-dev] Roadmap for Zope 3.4
On 9/12/06, Jim Fulton <[EMAIL PROTECTED]> wrote: 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 toblock the release. Ah. Well, that procedure definitely can get improved on. :) I think it is imperative that we mark bugs according to the seriousness so that you know which bug should be worked on first. I note that the Zope3 collector has the categories medium, low, critical, 3.3 release and 3.4 alpha 1. I don't think that's a good idea, but I understand that the Zope collector has no field for planned release, and those options make sense for features. :-) Anyway, for me it's like this: A blocking/critical bug is a bug that means the system or part of the system gets unusable. It has no workarounds, and affects most users of the system. Say, PUT_factory suddenly stops working, meaning that FTP and WebDAV no longer works. A serious/medium bug is a bug that is a big problem for many users and has no workaround, or affects everybody, but has a workaround. For example, that XML import/export didn't work: Workaround, use the non XML-import/export. A minor bug is a bug that affects few users and has a workaround, or has no workaround but only is a problem in very extreme edge usercases. For example...euhm, ehhh, I can't think of one right now. (and a trivial bug is not an actual problem for anybody. Could be spelling errors or ugly design.) A bug should be assigned a category and stay there. It should not get it's category changed so not block a release, because if you can do that, well, then it wasn't blocking in the first case. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Hi there, Jim Fulton wrote: >> I know. So Martijn and I both stepped forward a small bit on this. So we >> need some conflict resolution. :) > > Let Martijn do 3.3.1. Why don't you do 3.4. Actually dividing that job up to different people, maybe on a kind of rotation, sounds like a good plan. What do you think? I'd be more than happy to take over a release every now and then. This has multiple advantages: - more people will know how this works - it's easier to get people in and out - nobody has to commit for a very long time. >>> I'd be happy to come up with a minimal list, but I'm sure you'll think >>> of tasks I won't. >> >> That would be nice. I'm putting up a todo for myself to come up with >> tasks, I'll also investigate if we have any material on zope.org that >> already describes this. > > I think that the making a release information is pretty good, as far as > it goes. I'll read that again. I'm more interested in the stuff that should be done before the release. 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
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 1:24 PM, Christian Theune wrote: Jim Fulton wrote: On Sep 12, 2006, at 10:50 AM, Christian Theune wrote: Jim Fulton wrote: On Sep 12, 2006, at 10:33 AM, Christian Theune wrote: - I think we want a release manager. You're a genius! I'll just snap my fingers. What happened after you snapped? :) You became the release manager. Welcome aboard! I was kidding. I know. So Martijn and I both stepped forward a small bit on this. So we need some conflict resolution. :) Let Martijn do 3.3.1. Why don't you do 3.4. I'd be happy to come up with a minimal list, but I'm sure you'll think of tasks I won't. That would be nice. I'm putting up a todo for myself to come up with tasks, I'll also investigate if we have any material on zope.org that already describes this. I think that the making a release information is pretty good, as far as it goes. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Martijn Faassen wrote at 2006-9-12 11:25 +0200: > ... >On the one hand core developers seem to be happy to use the trunk for >development projects, and on the other hand we demand a lot of work >doing bugfixes in a release, up to the point where we delay the release >itself. "core developers" probably have other means than "simple" Zope3 users. When you see some problems "simple" Zope2 users have, you may understand that they should not be bothered with bugs in addition... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Jim Fulton wrote: > On Sep 12, 2006, at 10:50 AM, Christian Theune wrote: >> Jim Fulton wrote: >>> On Sep 12, 2006, at 10:33 AM, Christian Theune wrote: >> - I think we want a release manager. > > You're a genius! I'll just snap my fingers. What happened after you snapped? :) >>> >>> You became the release manager. Welcome aboard! > > I was kidding. I know. So Martijn and I both stepped forward a small bit on this. So we need some conflict resolution. :) I acknowledge the importance of the task and I'd do it, but I don't want to put down anybody who is enthusiastic about it. >> Can I make you my assistant? > > I'd be happy to make the actual releases (tar balls and windos > installers) if someone else would do everything else. > Of course, this could be multiple people. I'm not interested in nagging > people. I'm happy to help set schedules, but I'd be happier not to be in > charge. I understand that. >> I might get argued into doing that, if the contract that is put on my >> head states clearly what my tasks are. If the tasks are unclear, I won't >> do it. I'd be happy to help with clearing up the tasks, but I would need >> a jump start from someone else (Philipp, Stephan, Jim?). > > I'd be happy to come up with a minimal list, but I'm sure you'll think > of tasks I won't. That would be nice. I'm putting up a todo for myself to come up with tasks, I'll also investigate if we have any material on zope.org that already describes this. 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
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 10:50 AM, Christian Theune wrote: Hi, Jim Fulton wrote: On Sep 12, 2006, at 10:33 AM, Christian Theune wrote: - I think we want a release manager. You're a genius! I'll just snap my fingers. What happened after you snapped? :) You became the release manager. Welcome aboard! I was kidding. Can I make you my assistant? I'd be happy to make the actual releases (tar balls and windos installers) if someone else would do everything else. Of course, this could be multiple people. I'm not interested in nagging people. I'm happy to help set schedules, but I'd be happier not to be in charge. I might get argued into doing that, if the contract that is put on my head states clearly what my tasks are. If the tasks are unclear, I won't do it. I'd be happy to help with clearing up the tasks, but I would need a jump start from someone else (Philipp, Stephan, Jim?). I'd be happy to come up with a minimal list, but I'm sure you'll think of tasks I won't. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On Tuesday 12 September 2006 10:13, 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. Right, I just look for bugs that sound like anything serious and not just a wish. When I tag a bug as critical or for a certain release, I am basically telling the bug fixer to look at it and evaluate whether it needs to be fixed. Jim has often overturned my status settings of bugs, and that is perfectly fine. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Hey, Jim Fulton wrote: [snip] 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. -1 Why, do you think we should allow old bugs to languish forever? I think this would be a bad thing to do after every release, though you could do it for a release once every while, I guess. Volunteer effort in one area doesn't transfer necessarily to volunteer effort in another area, though. You'd block contributors who were interested in moving the trunk forward, or force them to do it on their own branch. [snip] I think such a larger audience needs to grow organically and has fairly little to do with the bugfixing issues. We disagree. Okay, to make it clear: a) I believe that getting timely releases with new features out can help grow the audience for Zope. b) I believe that having high-quality .0 releases can grow the audience for Zope. c) I believe Zope 3 trunk at arbitrary points in time is already a fairly high-quality release even without significant bugfix work being done, thanks to the focus on quality in the development process. People developing their applications against the trunk appear to share this opinion. d) I believe that doing bugfix releases can show a commitment to quality better than not doing bugfix releases. timely feature releases, high quality .0 releases, bugfix releases, they all contribute. My opinion is that timely feature releases are more important in growing an audience than high quality .0 releases, for the reason that people need to actually do significant work with .0 releases to run into bugs, and thus are not entirely new audience (unless .0 is seriously botched and doesn't actually work - that's a worst case scenario I discuss below). I believe that new people who run into bugs would not be pushed away from Zope 3 very much if it was clear to them bugfix releases happened regualrly. Who or what would have been hurt exactly had Zope 3.3 been released in june? Well, we would have been hurt badly as the first beta release, the one made at around that time was badly broken. Who is we? Why would we have been hurt? Because the first beta release wasn't even tested by the person who made it. Critical bits were missing. If we had released it as a final release, we would have looked like fools. What about releasing it as a rc1? That's what release candidates are for. Even if we'd have made it .0 (which is not what I'm suggesting), we would've looked like fools only until we fixed it in a quick .1 release with a self-deprecating message. Even if such a badly broken beta would've gone out (which I was not suggesting, obviously we do *some* testing), we could've done a bugfix release. It would have been a major embarrassment. I don't know if you've noticed some recent threads, but Zope 3 has some serious credibility issues in the larger world. The larger world being Chris Withers? :) Do threads on zope3-dev count as 'the larger world'? Perhaps I missed some thread. We would have demonstrated pretty clearly that we don't care about quality. To whom? To pretty much everyone who pays any attention to what we're doing. That's not many people, so no biggie. Let's try to get more people to pay attention to what we're doing first. :) What if we'd have followed up with bugfix releases? And what makes you think we'd to that well. If we can get the first release so badly botched, what makes you think people will evenbother with later releases. Again, going with the hypothetical worst-case scenario where we made a completely botched release: * Because I bother with trying later releases if a current release of software doesn't work. * Because the window in which we'd release the buggy release and fix the bug would be small, and people get the latest bugfix release when they download. * Because linux distributions have packagers who put in the bugfix release instead of the botched release, so that many people don't even see the botched release. * Because many people on windows try windows installers anyway, and the person making the windows installer would see the brokenness. What about demonstrating we can release when we say we will? Releasing crap on time is not acceptable to me. So the state of the trunk in june was, in your evaluation, "crap" in june? I don't think it's Zope 3's reputation that would've been hurt, as Zope 3.3 in june was not *that* buggy. Bugfix releases are also a completely accepted practice. Except that we don't do much of those and we put little effort into the ones we do do. Let's do more bugfix releases. I don't think they can be avoided anyway. Agreed. Who's going to do it? Who's going to fix the bugs? Let's work on a plan so we're going to do this. Given such a plan, and assuming clear instructions are available, I volunteer to make the Zope 3.3.1 bugfix release. R
Re: [Zope3-dev] Roadmap for Zope 3.4
Hi, Jim Fulton wrote: > > On Sep 12, 2006, at 10:33 AM, Christian Theune wrote: - I think we want a release manager. >>> >>> You're a genius! I'll just snap my fingers. >> >> What happened after you snapped? :) > > You became the release manager. Welcome aboard! Can I make you my assistant? Do I get free health care? I might get argued into doing that, if the contract that is put on my head states clearly what my tasks are. If the tasks are unclear, I won't do it. I'd be happy to help with clearing up the tasks, but I would need a jump start from someone else (Philipp, Stephan, Jim?). >> Does the application of irony indicate that we (I) should get over it >> and ignore the problem (for now)? > > No, only that talk is cheap. I apologize for the irony. This talk of > "just release whatever we have on date X no matter what shape it's in > and ignore all the other issues we have" puts me in a ornery mode, the > best side of which is irony. I hope I didn't argue for that because I don't think we should sacrifice quality. - 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? > > Yeah, but not now. I'll put this in my tickler file to raise it again if nobody else does. 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
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote: - I think we want a release manager. You're a genius! I'll just snap my fingers. What happened after you snapped? :) You became the release manager. Welcome aboard! Does the application of irony indicate that we (I) should get over it and ignore the problem (for now)? No, only that talk is cheap. I apologize for the irony. This talk of "just release whatever we have on date X no matter what shape it's in and ignore all the other issues we have" puts me in a ornery mode, the best side of which is irony. Do we want to find a way how to go without a release manager? No. 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. I'm happy to discuss solutions. I've mentioned some ideas. I just can't accept a fixed release schedule that sacrifices quality. - 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? Yeah, but not now. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 9:53 AM, Christian Theune wrote: 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, This is just common sense. figuring out what release is immanent, But we have a release schedule/ what the repository status is, ... What does this mean? 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). So what? Come on, this isn't rocket science. 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. Want a degree? 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. Then again, sometimes people just need to apply common sense. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
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 - [EMAI
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 9:50 AM, Martijn Faassen wrote: Jim Fulton wrote: On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote: [snip] One problem we have is getting things to be tested. It hardly motivates people to test for and report bugs if their reports don't affect he release. I think we have a serious problem that needs to be addressed. I don't think the right way to address it is to release despite known serious bugs. Note that some judgement goes into considering whether a bug is serious enough to block a release. We don't block a release for just any bug. Before a release, bug triaging needs to take place. Which we do. I know, but perhaps we need to be a bit more aggressive. Christian Theune's point about empowerment to defer a bug may be useful. We may be a bit too fearful sometimes to defer bugs right now. I recall you saying we defer bugs too often and bugs never get fixed, so we should stop doing any feature work until all bugs are fixed, etc. We should. We have yet to do this. As I mentioned in another note, we should prevent new features at the beginning of a release cycle until we've caught up on past bugs. Trying to address old bugs was not responsible for the delays in the 3.3 release. I think it contributed, though fully agreed it isn't the only source of the delay. I call that perfectionistic. Then your idea of perfection and mine are far apart. Letting bugs languish for months or even years is not acceptable. Ignoreing bugs reported during beta testing, when we get too little testing to begin with is unacceptable. *Ignoring* bugs is unacceptable. Explicitly deferring a bug for months is acceptable, as there are always more bugs than we can fix, and we should fix the bugs of the highest priority. A low- priority bug may therefore languish. I'm not saying we are doing this correctly *now*, but such would be a reasonable process. I think we have been blocking this release with a selection of bugs that included quite a few that weren't absolutely critical. Name a few. Good point. Going through the bugs fixed over the last period makes them seem all important to me or alternatively, lesser important bugs fixed by the reporter themselves. Perhaps a hard-headed release manager who will say "important schrimportant" and defers the issues anyway would've been useful. Still: http://www.zope.org/Collectors/Zope3-dev/553 http://www.zope.org/Collectors/Zope3-dev/576 http://www.zope.org/Collectors/Zope3-dev/540 http://www.zope.org/Collectors/Zope3-dev/530 http://www.zope.org/Collectors/Zope3-dev/537 http://www.zope.org/Collectors/Zope3-dev/583 http://www.zope.org/Collectors/Zope3-dev/534 None of these blocked the release. Some issues were only discovered way after we should've done the release. We've been fixing these as part of the release process. All of these issues appear to be reported after mid-july or later, though. I think those are good bugfix release candidates, and shouldn't have been blocking our 3.3 release (not all of them are marked critical, but these all have been fixed): Since these all were reported in july or later, we couldn't possibly have fixed them if we'd have released in june. :) But these didn't cause us not to have a release in June. These were reported by beta testers. Why should people test betas if we aren't going to address the problems they report. If you aren't going to fix problems reported in beta releases, then you shouldn't have beta releases. If you don't have beta releases then the .0 releases are beta releases and the ,1 (hopefully) become the closest thing to final releases and we barely do those. In any case, the final release is delayed. No, but it will halve the work for the small existing group of volunteers. I do not believe this to be necessarily the case. The list of bugs fixed that were reported after our supposed june release is one reason why I think that. The other reason is that there'd be two times as much space between bugfixing rounds, which will make bugs languish and people get out of the habit of fixing them. Well, if we slow down the number of features introduced, then, hopefully, the software will stabilize and there will be fewer bugs to fix. 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. -1 Why, do you think we should allow old bugs to languish forever? 3. Release less. I think it's time to start thinking of some sort of "core" Zope 3 that we can manage with the very limited number of volunteers we have now. +1, though I wonder how much this has been blocking the release - important bugs that could block releases don't tend to be in out of the way components, one would think. I spent a lot of time on crap that wasn't core at all. So why were these critical issues? What happened during triaging? They w
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 9:17 AM, Christian Theune wrote: Then your idea of perfection and mine are far apart. Letting bugs languish for months or even years is not acceptable. Ignoreing bugs reported during beta testing, when we get too little testing to begin with is unacceptable. I agree on that. However, we have a bad history lurking in the collector and I think we should be a bit more forgiving about not fixing old bugs immediately (obviously they can't be that urgent) but apply more care to the new bugs from testing periods. That narrows the area of focus a bit and makes it easier for us to massage them. Right, that's why none of these blocked the release just because they were old. I think we have been blocking this release with a selection of bugs that included quite a few that weren't absolutely critical. Name a few. I know a few bugs that weren't important but fixed by me, because I wanted to spend some bugfixing time but didn't find any higher priority bugs that I could tackle. That's fine, but they didn't block the release. I know that I have been delaying one fix that took me weeks because I underestimated the effort. Probably, I should have given a heads-up on me beeing stuck there earlier. Yup. I think you and I agree that this was a critical bug that should have blocked the release. There was also a ZODB test failure on Mac OS X that I felt was critical. I spent weeks on this. In retrospect,we should have shipped Zope 3.3 using ZODB 3.6, although that too had Mac OS X problems. I would suggest we triage bugs a lot more aggressively instead. I say this as someone who spent a few afternoons staring at Zope 3 bugs trying to get them out of the way. I've spent way more than a few afternoons. As a contributor, you have the luck to be able to make decisions about pretty much everything regarding the code base, where others need to rely on comments on the mailinglist because intricate knowledge is missing. I don't know what this has to do with commit access. I agree that a lot of knowledge is often needed, although I worked on a lot of shallow bugs that others could have worked on. This would mean the requirement for volunteers might need rephrasing: We need a sufficient number of volunteers that are familiar enough with our process and Zope to make maintenance easier for everybody. Sure. I don't agree that the process is that complicated. No, but it will halve the work for the small existing group of volunteers. Only if the volunteers are qualified enough. The volunteers we have now are obviously qualified enough. If we don't get more, we have to give them less work. On the other hand, a lot of the bugs in the collector would be easier to fix if the - descriptions and reproducability would be better Sure, OTOH, it's easy to ask for clarification and to reject the issue if a clarification is not forthcoming. If we did this continually, rather than waiting until just before the release, this would be very easy. - if decisions that need to be done are put in there immediately Volunteers are needed to make that decision. 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. 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. 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. Wei
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 8:57 AM, Jim Fulton wrote: I still think our quality standards for a release have been too high. Getting people to fix more bugs is good, sure, but perhaps we should separate this at least somewhat from the release itself. Sorry, I agree very much. I'd be willing to defer to a Zope 3 release manager, if there was one. I mean I disagree very much. Sigh. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
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 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
Re: [Zope3-dev] Roadmap for Zope 3.4
Jim Fulton wrote: On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote: [snip] One problem we have is getting things to be tested. It hardly motivates people to test for and report bugs if their reports don't affect he release. I think we have a serious problem that needs to be addressed. I don't think the right way to address it is to release despite known serious bugs. Note that some judgement goes into considering whether a bug is serious enough to block a release. We don't block a release for just any bug. Before a release, bug triaging needs to take place. Which we do. I know, but perhaps we need to be a bit more aggressive. Christian Theune's point about empowerment to defer a bug may be useful. We may be a bit too fearful sometimes to defer bugs right now. I recall you saying we defer bugs too often and bugs never get fixed, so we should stop doing any feature work until all bugs are fixed, etc. We should. We have yet to do this. As I mentioned in another note, we should prevent new features at the beginning of a release cycle until we've caught up on past bugs. Trying to address old bugs was not responsible for the delays in the 3.3 release. I think it contributed, though fully agreed it isn't the only source of the delay. I call that perfectionistic. Then your idea of perfection and mine are far apart. Letting bugs languish for months or even years is not acceptable. Ignoreing bugs reported during beta testing, when we get too little testing to begin with is unacceptable. *Ignoring* bugs is unacceptable. Explicitly deferring a bug for months is acceptable, as there are always more bugs than we can fix, and we should fix the bugs of the highest priority. A low-priority bug may therefore languish. I'm not saying we are doing this correctly *now*, but such would be a reasonable process. I think we have been blocking this release with a selection of bugs that included quite a few that weren't absolutely critical. Name a few. Good point. Going through the bugs fixed over the last period makes them seem all important to me or alternatively, lesser important bugs fixed by the reporter themselves. Perhaps a hard-headed release manager who will say "important schrimportant" and defers the issues anyway would've been useful. Still: http://www.zope.org/Collectors/Zope3-dev/553 http://www.zope.org/Collectors/Zope3-dev/576 http://www.zope.org/Collectors/Zope3-dev/540 http://www.zope.org/Collectors/Zope3-dev/530 http://www.zope.org/Collectors/Zope3-dev/537 http://www.zope.org/Collectors/Zope3-dev/583 http://www.zope.org/Collectors/Zope3-dev/534 Some issues were only discovered way after we should've done the release. We've been fixing these as part of the release process. All of these issues appear to be reported after mid-july or later, though. I think those are good bugfix release candidates, and shouldn't have been blocking our 3.3 release (not all of them are marked critical, but these all have been fixed): http://www.zope.org/Collectors/Zope3-dev/677 http://www.zope.org/Collectors/Zope3-dev/675 http://www.zope.org/Collectors/Zope3-dev/676 http://www.zope.org/Collectors/Zope3-dev/679 http://www.zope.org/Collectors/Zope3-dev/674 http://www.zope.org/Collectors/Zope3-dev/683 http://www.zope.org/Collectors/Zope3-dev/681 http://www.zope.org/Collectors/Zope3-dev/683 http://www.zope.org/Collectors/Zope3-dev/682 http://www.zope.org/Collectors/Zope3-dev/680 http://www.zope.org/Collectors/Zope3-dev/673 http://www.zope.org/Collectors/Zope3-dev/690 http://www.zope.org/Collectors/Zope3-dev/696 http://www.zope.org/Collectors/Zope3-dev/691 http://www.zope.org/Collectors/Zope3-dev/697 Since these all were reported in july or later, we couldn't possibly have fixed them if we'd have released in june. :) I would suggest we triage bugs a lot more aggressively instead. I say this as someone who spent a few afternoons staring at Zope 3 bugs trying to get them out of the way. I've spent way more than a few afternoons. Gratefully acknowledged. I can think of a number of ways to approach this problem: 1. Do less frequent releases. I do not believe this helps a lot for bug fixes. If we have twice the release period, people won't start fixing bugs twice the amount of time in advance, Right. This, alone is not a solution. and we won't get twice the volunteers either. No, but it will halve the work for the small existing group of volunteers. I do not believe this to be necessarily the case. The list of bugs fixed that were reported after our supposed june release is one reason why I think that. The other reason is that there'd be two times as much space between bugfixing rounds, which will make bugs languish and people get out of the habit of fixing them. 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 t
Re: [Zope3-dev] Roadmap for Zope 3.4
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. 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. 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. 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. ... 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. +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. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Hi, Jim Fulton wrote: > > On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote: > >> Jim Fulton wrote: >>> On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote: >> [snip] Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. >>> Maybe they have more volunteers. >> >> Yes. They also have a *lot* more to release. Their release story is >> also massively more complicated than ours. And they release, on the >> day they say they will release. It's too easy to say they do this >> because they had sufficient amounts of volunteers. > > All I know is that we don't have enough volunteers. Too few of us do > way too much of the work, Do we have a list of all (semi-)active committers that we might brainwash to be a little bit more active? :) >> I call that perfectionistic. > > Then your idea of perfection and mine are far apart. Letting bugs > languish for months or even years is not acceptable. Ignoreing bugs > reported during beta testing, when we get too little testing to begin > with is unacceptable. I agree on that. However, we have a bad history lurking in the collector and I think we should be a bit more forgiving about not fixing old bugs immediately (obviously they can't be that urgent) but apply more care to the new bugs from testing periods. That narrows the area of focus a bit and makes it easier for us to massage them. >> I think we have been blocking this release with a selection of bugs >> that included quite a few that weren't absolutely critical. > > Name a few. I know a few bugs that weren't important but fixed by me, because I wanted to spend some bugfixing time but didn't find any higher priority bugs that I could tackle. I know that I have been delaying one fix that took me weeks because I underestimated the effort. Probably, I should have given a heads-up on me beeing stuck there earlier. >>> I would suggest we triage bugs a lot more aggressively instead. I say >>> this as someone who spent a few afternoons staring at Zope 3 bugs >>> trying to get them out of the way. > > I've spent way more than a few afternoons. As a contributor, you have the luck to be able to make decisions about pretty much everything regarding the code base, where others need to rely on comments on the mailinglist because intricate knowledge is missing. This would mean the requirement for volunteers might need rephrasing: We need a sufficient number of volunteers that are familiar enough with our process and Zope to make maintenance easier for everybody. >>> I can think of a number of ways to approach this problem: >>> 1. Do less frequent releases. >> >> I do not believe this helps a lot for bug fixes. If we have twice the >> release period, people won't start fixing bugs twice the amount of >> time in advance, > > Right. This, alone is not a solution. Me too. Seems like an agreed point. >> and we won't get twice the volunteers either. > > No, but it will halve the work for the small existing group of volunteers. Only if the volunteers are qualified enough. On the other hand, a lot of the bugs in the collector would be easier to fix if the - descriptions and reproducability would be better - if decisions that need to be done are put in there immediately Sometimes it feels to me that when Stephan or you prioritize a bug that you have a rough understanding of the solution, and it would be really great if you could put in a small draft of the solution you imagine. I think that would be helpful to bugfixers. >>> 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? 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. >>> 3. Release less. I think it's time to start thinking of some sort of >>> "core" Zope 3 that we can manage with the very limited number of >>> volunteers we have now. >> >> +1, though I wonder how much this has been blocking the release - >> important bugs that could block releases don't tend to be in out of >> the way components, one would think. > > I spent a lot of time on crap that wasn't core at all. Can't remember exactly, but I think I did too. >>> 4. Get more volunteers. >> >> Getting a release out is *difficult* and the amount of volunteers >> available, whil
Re: [Zope3-dev] Roadmap for Zope 3.4
Morning, Martijn Faassen wrote: >> I don't think our problem has been perfectionism. I think our problem >> has been a lack of will to fix things in a timely manner. > >> One problem we have is getting things to be tested. It hardly >> motivates people to test for and report bugs if their reports don't >> affect he release. >> >> I think we have a serious problem that needs to be addressed. I don't >> think the right way to address it is to release despite known serious >> bugs. Note that some judgement goes into considering whether a bug is >> serious enough to block a release. We don't block a release for just >> any bug. > > Before a release, bug triaging needs to take place. I recall you saying > we defer bugs too often and bugs never get fixed, so we should stop > doing any feature work until all bugs are fixed, etc. I call that > perfectionistic. > > I think we have been blocking this release with a selection of bugs that > included quite a few that weren't absolutely critical. I would suggest > we triage bugs a lot more aggressively instead. I say this as someone > who spent a few afternoons staring at Zope 3 bugs trying to get them out > of the way. 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. 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. 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 can think of a number of ways to approach this problem: >> >> 1. Do less frequent releases. > > I do not believe this helps a lot for bug fixes. If we have twice the > release period, people won't start fixing bugs twice the amount of time > in advance, and we won't get twice the volunteers either. I think the > same amount of people will start fixing bugs the same amount of time > before the release. You could say we get less overhead with more > releases so people would be able to free up more time to work on the > release, but on the other hand if a release cycle takes longer the more > chance is that people will get out of the habit of fixing bugs. > > A longer release cycle may help a bit for complicated feature work, but > I don't think it'll help there a lot too, because if a new feature > cannot be written and mature in the space of 6 months, it has no > business being in the core yet anyway. I agree on this reasoning. >> 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) >> 3. Release less. I think it's time to start thinking of some sort of >> "core" Zope 3 that we can manage with the very limited number of >> volunteers we have now. > > +1, though I wonder how much this has been blocking the release - > important bugs that could block releases don't tend to be in out of the > way components, one would think. Jup. And I share the hopes that eggification will make that easier. Together with this, I think that our roadmap should layout not only the dates when releases happen, but what we *think* will be part of the feature set. I'm very split about doing releases on a timely manner without any features in it. There seems no point. On the other side I do agree to favor smaller releases instead of extending the feature develepment period. E.g. does it make any sense to release Zope 3.4 without the eggification? It seems to be the only major feature except from bug fixes, minor features and restructuring. >> 4. Get more volunteers. > > Getting a release out is *difficult* and the amount of volunteers > available, while important, is only partially related. More volunteers > won't speed it up tremendously much and can even slow things down. Plone > has many volunteers and has had much problems in the past doing timely > releases. Silva has had far less volunteers and can do more agile > releases, because there's less people to manage. > >> These are just some ideas. But something has to give and I don't think >> it should be responsible bug fixing prior to release. > > Large Zope 3 projects have been working against 3.3 for many months
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote: Jim Fulton wrote: On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote: [snip] Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. Maybe they have more volunteers. Yes. They also have a *lot* more to release. Their release story is also massively more complicated than ours. And they release, on the day they say they will release. It's too easy to say they do this because they had sufficient amounts of volunteers. All I know is that we don't have enough volunteers. Too few of us do way too much of the work, I don't think our problem has been perfectionism. I think our problem has been a lack of will to fix things in a timely manner. One problem we have is getting things to be tested. It hardly motivates people to test for and report bugs if their reports don't affect he release. I think we have a serious problem that needs to be addressed. I don't think the right way to address it is to release despite known serious bugs. Note that some judgement goes into considering whether a bug is serious enough to block a release. We don't block a release for just any bug. Before a release, bug triaging needs to take place. Which we do. I recall you saying we defer bugs too often and bugs never get fixed, so we should stop doing any feature work until all bugs are fixed, etc. We should. We have yet to do this. As I mentioned in another note, we should prevent new features at the beginning of a release cycle until we've caught up on past bugs. Trying to address old bugs was not responsible for the delays in the 3.3 release. I call that perfectionistic. Then your idea of perfection and mine are far apart. Letting bugs languish for months or even years is not acceptable. Ignoreing bugs reported during beta testing, when we get too little testing to begin with is unacceptable. I think we have been blocking this release with a selection of bugs that included quite a few that weren't absolutely critical. Name a few. I would suggest we triage bugs a lot more aggressively instead. I say this as someone who spent a few afternoons staring at Zope 3 bugs trying to get them out of the way. I've spent way more than a few afternoons. I can think of a number of ways to approach this problem: 1. Do less frequent releases. I do not believe this helps a lot for bug fixes. If we have twice the release period, people won't start fixing bugs twice the amount of time in advance, Right. This, alone is not a solution. and we won't get twice the volunteers either. No, but it will halve the work for the small existing group of volunteers. 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. ... 3. Release less. I think it's time to start thinking of some sort of "core" Zope 3 that we can manage with the very limited number of volunteers we have now. +1, though I wonder how much this has been blocking the release - important bugs that could block releases don't tend to be in out of the way components, one would think. I spent a lot of time on crap that wasn't core at all. 4. Get more volunteers. Getting a release out is *difficult* and the amount of volunteers available, while important, is only partially related. More volunteers won't speed it up tremendously much and can even slow things down. Plone has many volunteers and has had much problems in the past doing timely releases. Silva has had far less volunteers and can do more agile releases, because there's less people to manage. And because it is much smaller. I think we're far from having too many volunteers on Zope 3 maintenance. I'm not optimistic that we'll get more volunteers, which is why I'm inclined to release less. These are just some ideas. But something has to give and I don't think it should be responsible bug fixing prior to release. Large Zope 3 projects have been working against 3.3 for many months now. If there was any absolute showstopper in Zope 3.3, why have these projects successfully transitioned? It all depends on how large you want the audience to Zope 3 to be. A small community on a limited number of platforms can work around well- known problems. Who or what would have been hurt exactly had Zope 3.3 been released in june? Well, we would have been hurt badly as the first beta release, the one made at around that time was badly broken. There were some serious bugs. We would have demonstrated pr
Re: [Zope3-dev] Roadmap for Zope 3.4
Jim Fulton wrote: On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote: [snip] Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. Maybe they have more volunteers. Yes. They also have a *lot* more to release. Their release story is also massively more complicated than ours. And they release, on the day they say they will release. It's too easy to say they do this because they had sufficient amounts of volunteers. I don't think our problem has been perfectionism. I think our problem has been a lack of will to fix things in a timely manner. One problem we have is getting things to be tested. It hardly motivates people to test for and report bugs if their reports don't affect he release. I think we have a serious problem that needs to be addressed. I don't think the right way to address it is to release despite known serious bugs. Note that some judgement goes into considering whether a bug is serious enough to block a release. We don't block a release for just any bug. Before a release, bug triaging needs to take place. I recall you saying we defer bugs too often and bugs never get fixed, so we should stop doing any feature work until all bugs are fixed, etc. I call that perfectionistic. I think we have been blocking this release with a selection of bugs that included quite a few that weren't absolutely critical. I would suggest we triage bugs a lot more aggressively instead. I say this as someone who spent a few afternoons staring at Zope 3 bugs trying to get them out of the way. I can think of a number of ways to approach this problem: 1. Do less frequent releases. I do not believe this helps a lot for bug fixes. If we have twice the release period, people won't start fixing bugs twice the amount of time in advance, and we won't get twice the volunteers either. I think the same amount of people will start fixing bugs the same amount of time before the release. You could say we get less overhead with more releases so people would be able to free up more time to work on the release, but on the other hand if a release cycle takes longer the more chance is that people will get out of the habit of fixing bugs. A longer release cycle may help a bit for complicated feature work, but I don't think it'll help there a lot too, because if a new feature cannot be written and mature in the space of 6 months, it has no business being in the core yet anyway. 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. 3. Release less. I think it's time to start thinking of some sort of "core" Zope 3 that we can manage with the very limited number of volunteers we have now. +1, though I wonder how much this has been blocking the release - important bugs that could block releases don't tend to be in out of the way components, one would think. 4. Get more volunteers. Getting a release out is *difficult* and the amount of volunteers available, while important, is only partially related. More volunteers won't speed it up tremendously much and can even slow things down. Plone has many volunteers and has had much problems in the past doing timely releases. Silva has had far less volunteers and can do more agile releases, because there's less people to manage. These are just some ideas. But something has to give and I don't think it should be responsible bug fixing prior to release. Large Zope 3 projects have been working against 3.3 for many months now. If there was any absolute showstopper in Zope 3.3, why have these projects successfully transitioned? Who or what would have been hurt exactly had Zope 3.3 been released in june? I don't think it's Zope 3's reputation that would've been hurt, as Zope 3.3 in june was not *that* buggy. Bugfix releases are also a completely accepted practice. I still think our quality standards for a release have been too high. Getting people to fix more bugs is good, sure, but perhaps we should separate this at least somewhat from the release itself. If we're going to do timebased releases, we should have a button somewhere that says 'make a release', and a date on which the button is pressed. If the release is botched, we can press the button again for bugfix releases, and we have 6 months in which to do a better job next time. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote: Hi there, Thanks for doing this work, Christian. I'm in favor of going for Zope 3.4 on a timely basis. Concerning the delay of Zope 3.3, I think we should consider whether we're not too perfectionistic. On the one hand core developers seem to be happy to use the trunk for development projects, and on the other hand we demand a lot of work doing bugfixes in a release, up to the point where we delay the release itself. That's a bit paradoxical - evidently the bugs aren't harmful enough to harm these developers much most of the time, but at the same time we consider them extremely harmful if they should appear in a release. What about a policy where we fix bugs until the release date, and then on the release date, we actually release? Any bugs that are still in it are going to go with it. Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. Maybe they have more volunteers. I don't think our problem has been perfectionism. I think our problem has been a lack of will to fix things in a timely manner. One problem we have is getting things to be tested. It hardly motivates people to test for and report bugs if their reports don't affect he release. I think we have a serious problem that needs to be addressed. I don't think the right way to address it is to release despite known serious bugs. Note that some judgement goes into considering whether a bug is serious enough to block a release. We don't block a release for just any bug. I can think of a number of ways to approach this problem: 1. Do less frequent releases. 2. Feature freeze the trunk until the previous release has made it to release candidate status 3. Release less. I think it's time to start thinking of some sort of "core" Zope 3 that we can manage with the very limited number of volunteers we have now. 4. Get more volunteers. These are just some ideas. But something has to give and I don't think it should be responsible bug fixing prior to release. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On 9/12/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: What about a policy where we fix bugs until the release date, and then on the release date, we actually release? Any bugs that are still in it are going to go with it. I totally agree. My feeling is that the x.x.0 release this time will be at least as stable as a x.x.1 release normally, maybe even more stable. Of course, it's bad to have to release a x.x.0 release to find bugs, but not enough people outside the developer world will actually install a beta or RC for that to be realistic. Remember: If all the tests pass, it's ready for a release! :-) Also, it seems to me that slippage is worse because we slip until we slip into vacation, which makes us slip even more. I even have the feeling that people go "It's xmas soon, Iäll fix it then" and of course you end up sleeping through xmas and eating too much instead of programming. I know I do. :) So, I'm more for a March/September cycle for these reasons. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Hi there, Thanks for doing this work, Christian. I'm in favor of going for Zope 3.4 on a timely basis. Concerning the delay of Zope 3.3, I think we should consider whether we're not too perfectionistic. On the one hand core developers seem to be happy to use the trunk for development projects, and on the other hand we demand a lot of work doing bugfixes in a release, up to the point where we delay the release itself. That's a bit paradoxical - evidently the bugs aren't harmful enough to harm these developers much most of the time, but at the same time we consider them extremely harmful if they should appear in a release. What about a policy where we fix bugs until the release date, and then on the release date, we actually release? Any bugs that are still in it are going to go with it. Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Roadmap for Zope 3.4
Hi, as we're running late already on Zope 3.3 and also running into the original alloted time for 3.4, I've taken a minute to update the RoadMap [1]. As far as I understand the grand plan for Zope 3.4 is the eggification. I don't see any proposal attached to that, but we better get this rolling if we want a somewhat timely 3.4 release. I also propose to favor a smaller but timely 3.4 release. Philipp made the suggestion to ignore 3.4 in December and move it to the next release cycle, but I'm against that because we can make a smaller release much easier than a release that is even larger. Another option that would be possible, but would cripple innovation eventually, is to postpone 3.4 but keep the feature set as small as possible. Anyway, we have to agree on a change of deadlines for 3.4, as the alpha would be this week. Christian [1] ... http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/RoadMap -- 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
