[Zope3-dev] Re: give ability to get rid of deprecated code
Benji York zope.com> writes: > > Florent Xicluna wrote: > > I am working on a 'light' version of Zope > > You may want to contribute toward "eggifying" Zope 3 for the next > release. Once Z3 is sufficiently broken into individual components, > projects can use as few (or many) as they need. sure! By the way, I have to read more about eggs usage and benefits. First experience with eggs was not easy, because the server where I need to install egg was not connected to internet. -- Florent ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: give ability to get rid of deprecated code
On 9/12/06, Florent Xicluna <[EMAIL PROTECTED]> wrote: Benji York zope.com> writes: > > Florent Xicluna wrote: > > I am working on a 'light' version of Zope > > You may want to contribute toward "eggifying" Zope 3 for the next > release. Once Z3 is sufficiently broken into individual components, > projects can use as few (or many) as they need. sure! By the way, I have to read more about eggs usage and benefits. First experience with eggs was not easy, because the server where I need to install egg was not connected to internet. Few Zope eggs are here : http://download.zope.org/distribution/ -- Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[3]: [Zope3-dev] possible bug in zope.wfmc
Hello Jim, As I think it further, even if I would implement the exception and so transitions, there might still be a chance that an activity does not have a valid outgoing transition. These transitions can also have conditions. Still I have to read through the WFMC specifications. Monday, September 11, 2006, 4:27:26 PM, I wrote: AG> Hello Jim, AG> My specific usecase is: AG> - AG> ->| Final | AG> -- / - AG>...-->>| Update |- - AG> -- \->| Issue |-->... AG> ^ \ - AG> |\-- AG> | \-->| Review | AG> | -- AG> | | AG> +--+ AG> Update ->> Final is guarded by "review_result == 'accepted'" Update ->> Issue is guarded by "transitionName == 'update_issue'" Update ->> Review is guarded by "transitionName == 'update_review'" AG> On the UI I put up every possible transition. Now if my crazy user AG> chooses Final if review_result != 'accepted' then bang, the AG> process gets finished. No errors, no messages, no exceptions. AG> I already thought of filtering the possible transitions on the UI, but AG> how? transitionName still forces the other conditions to false. A kind AG> of transition-precondition is not available as I know. AG> In this usecase raising an exception and thus not letting any AG> transition to fire fits me perfectly. AG> XPDL would give the options AG> - exception AG> - default exception AG> - otherwise AG> but none of these are implemented in zope.wfmc. AG> I think finishing the whole process is definitely bad behaviour. AG> But what's correct? Please give a hint what should be done. AG> Monday, September 11, 2006, 4:00:01 PM, you wrote: JF>> On Sep 10, 2006, at 9:00 AM, Adam Groszer wrote: >>> Hello, >>> >>> I think I found a bug in zope.wfmc. >>> Let's say the Review>Publish and Review>Reject transitions are guarded >>> by conditions. >>> --- >>>-->| Publish | >>> -- -- / --- >>> | Author |-->| Review |--- >>> -- -- \-->| Reject | >>> -- >>> >>> If at Review.workItemFinished() both conditions are still _FALSE_ the >>> wfmc package finishes the whole process. >>> I think the correct behaviour should be to not to allow to finish the >>> workitem. JF>> I don't think that would be correct. >>> Maybe an exception should be raised? JF>> You can actually model that in xpdl using an exception, although I JF>> don't reflect off-hand if that is supported in zope.wfmc. JF>> Jim JF>> -- JF>> Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! JF>> CTO (540) 361-1714 http://www.python.org JF>> Zope Corporationhttp://www.zope.com http://www.zope.org -- Best regards, Groszer Adam -- Quote of the day: Many would be scantily clad if clothed in their humility. - Anonymous ___ 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
Re: [Zope3-dev] Re: 3.3 release?
Philipp von Weitershausen wrote: Christian Theune wrote: what's the status on the release? We should have an RC and maybe a release in one or two weeks. Yup. We will be making an RC this week. Great! I started a discussion on What Went Wrong (tm) in Christian's roadmap thread. I'd be happy to see some more opinions. 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] Re: Roadmap for Zope 3.4
Martijn Faassen wrote: Thanks for doing this work, Christian. I'm in favor of going for Zope 3.4 on a timely basis. I wouldn't mind that. 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. I've come to wonder the same thing. 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. Yes, provided we have a release branch babysitter who will spit out new bugfix releases once a final release has been made. I'd be willing to do this for Zope 3.2, provided people actually do their bugfixes there. Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. I bet the Gnome project has members who are actually paid to do this kind of release management, though. That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Release schedule for Zope 2.11/3.4?
Hi all, since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? Andreas pgpIoIUF7RJpI.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Roadmap for Zope 3.4
Philipp von Weitershausen wrote: [snip] Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too. I bet the Gnome project has members who are actually paid to do this kind of release management, though. They probably have more resources than we have. Then again, a typical Gnome release consists of the release of *many* different projects, and I doubt that those releases are all done by people paid to do so. The coordination overhead of Gnome is a lot higher too, as well. That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :). Yes, the whole idea is that we never will have enough resources, so we just make do with what we have. The other idea is that it's easier to garner resources when you actually have a release in sight. I *think* the latter has been working at least to some extent for Zope, but we risk losing our credibility if it doesn't actually result in a release. You get the "Oh well, I'll participate in the bug day next week." effect. 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] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! Is the reasoning here that since a release cycle has taken 9 months, so should the next? I'm not convinced expanding the release cycle is going to make us be on time more. If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? That's one option. The other option is to stick with the plan and catch up, as Christian Theune proposed. It would mean getting very unambitious, but perhaps that isn't a bad idea. The idea of a release is to have a reasonably stable, known-good version of the trunk, and it doesn't matter that much how much the trunk changes. Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 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] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! Is the reasoning here that since a release cycle has taken 9 months, so should the next? I'm not convinced expanding the release cycle is going to make us be on time more. Not really, just a thought in order to stick with the June/December cycle...but not really an important argument. If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? That's one option. The other option is to stick with the plan and catch up, as Christian Theune proposed. It would mean getting very unambitious, but perhaps that isn't a bad idea. The idea of a release is to have a reasonably stable, known-good version of the trunk, and it doesn't matter that much how much the trunk changes. Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date. Andreas pgpSiZKwtHn0V.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Roadmap for Zope 3.4
Martijn Faassen wrote: That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :). Yes, the whole idea is that we never will have enough resources, so we just make do with what we have. The other idea is that it's easier to garner resources when you actually have a release in sight. I *think* the latter has been working at least to some extent for Zope, but we risk losing our credibility if it doesn't actually result in a release. You get the "Oh well, I'll participate in the bug day next week." effect. My sentiments exactly. If we decide to stick with the November release, 3.4/2.11 will be very very unambitious. I don't think 2.11 is any different from 2.10, except that some BBB code is to be removed. That makes me wonder: perhaps we should set the next release date for 6 months from now (March), like Andreas suggested on [EMAIL PROTECTED] Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: [snip] Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date. The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time. Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release? I think the egg-story is one candidate for being too big, and a possible reason to shift the release schedule. Then again, we do not need the egg story to land in the upcoming release anyway. 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] Re: Roadmap for Zope 3.4
Philipp von Weitershausen wrote: Martijn Faassen wrote: That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :). Yes, the whole idea is that we never will have enough resources, so we just make do with what we have. The other idea is that it's easier to garner resources when you actually have a release in sight. I *think* the latter has been working at least to some extent for Zope, but we risk losing our credibility if it doesn't actually result in a release. You get the "Oh well, I'll participate in the bug day next week." effect. My sentiments exactly. If we decide to stick with the November release, 3.4/2.11 will be very very unambitious. I don't think 2.11 is any different from 2.10, except that some BBB code is to be removed. That makes me wonder: perhaps we should set the next release date for 6 months from now (March), like Andreas suggested on [EMAIL PROTECTED] I would be okay with this, with the condition that we shouldn't go into this kind of slippage again, otherwise we'll keep cycling through the year. I really think we should seriously consider trading off release perfectionism against releasing on time. 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] Re: Roadmap for Zope 3.4
Martijn Faassen wrote: Philipp von Weitershausen wrote: Martijn Faassen wrote: That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :). Yes, the whole idea is that we never will have enough resources, so we just make do with what we have. The other idea is that it's easier to garner resources when you actually have a release in sight. I *think* the latter has been working at least to some extent for Zope, but we risk losing our credibility if it doesn't actually result in a release. You get the "Oh well, I'll participate in the bug day next week." effect. My sentiments exactly. If we decide to stick with the November release, 3.4/2.11 will be very very unambitious. I don't think 2.11 is any different from 2.10, except that some BBB code is to be removed. That makes me wonder: perhaps we should set the next release date for 6 months from now (March), like Andreas suggested on [EMAIL PROTECTED] I would be okay with this, with the condition that we shouldn't go into this kind of slippage again, otherwise we'll keep cycling through the year. I really think we should seriously consider trading off release perfectionism against releasing on time. +1 ___ 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
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: [snip] Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date. The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release. The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time. Not much happened during the three month or I did I miss something? Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release? We just don't have nothing new right now. Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow. Andreas I think the egg-story is one candidate for being too big, and a possible reason to shift the release schedule. Then again, we do not need the egg story to land in the upcoming release anyway. Regards, Martijn -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting pgpKzG0VOomAk.pgp Description: PGP 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 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
[Zope3-dev] Re: Release schedule for Zope 2.11/3.4?
On Sep 12, 2006, at 5:47 AM, Andreas Jung wrote: Hi all, since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? We were hoping two switch to May and November. I'd be for May for 2.11/3.4. 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
[Zope3-dev] zc.buildout: When is recipe.install run?
While using buildout in our recent project[1] we have discovered that some recipe's `install` method is being run although neither the recipe nor the configuration has changed. From reading the documentation I got the impression that whenever `install` is called, the parts directory (i.e. whatever I returned on last `install`) should have been cleaned up. However in our case, the `openoffice` recipe is seemingly been run although there haven't been any changes to the recipe or configuration. Further, the parts directory of the recipe is still in place when `install` is run. What can a recipe assume in `install`? And could the fact that I'm using `develop` in `[buildout]` trigger the install on each run? And shouldn't the parts directory be cleaned up everytime I am run? I was thinking that an `update` method would be useful for recipes to check if they need to do something even if recipe and configuration are the same. Any recipe that checks out from SVN would be using that update method. Daniel [1] https://infrae.com/svn/buildout/oooconv-dev/trunk/buildout.cfg ___ 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 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
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: --On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: [snip] Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date. The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release. It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all? Zope 2 also includes Zope 3, so that might help feature-wise. The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time. Not much happened during the three month or I did I miss something? So imagine we had done the release in june as we planned and everything else would be the same. Would that mean we would've canceled the next release, as we'd only have 1 new feature? Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release? We just don't have nothing new right now. That could then not be affecting the solidity of the release, just how interesting the release is. :) Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow. That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer) What do you think about a 9 month release cycle? 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 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
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
[Zope3-dev] Re: zc.buildout: When is recipe.install run?
Hey, [posting this to zope3-dev too so the discussion thread there is somewhat intact] Jim Fulton wrote: On Sep 12, 2006, at 8:32 AM, Daniel Nouri wrote: While using buildout in our recent project[1] we have discovered that some recipe's `install` method is being run although neither the recipe nor the configuration has changed. The install method is always called. Clever install methods can usually decode how much work to do depending on the presense of installed files. Why should install methods have to be this clever? Having this capability also puts a bit of a burden on the install method, which wouldn't be the case if this would be handled by an 'update' method. [snip] And shouldn't the parts directory be cleaned up everytime I am run? No. The buildout software never cleans out the parts directory. It removes paths returned from prior calls to install if and only if the configuration or recipe has changed, I was thinking that an `update` method would be useful for recipes to check if they need to do something even if recipe and configuration are the same. Any recipe that checks out from SVN would be using that update method. If you want to do an svn update, do it in install. We actually didn't have the goal of doing an svn update at all. In fact, we have a buildout that really shouldn't do anything if it's already installed, and we were forced to add code to our buildout that checks for the part being already present and bailing out if so. The 'svn update' usecase is the reason we could think of why install is always called, even if recipe and buildout config hasn't changed. Right now the install method can be called in a number of different cases: a) when the part isn't there yet b) when the part is there, and the configuration or recipe has changed. In this case the part is removed again automatically, so this is equivalent to a). c) when the part is there, and the recipe and configuration have not changed. In this case there needs to be code that bails out if the part is there and looks okay, or alternatively update code that updates the part (svn up). Case c) looks different. If there was an update method that got called in case c), the install method wouldn't need to be called anymore, and: * the install method can *always* assume the part isn't there and that it needs to freshly install it. * the update method can *always* assume the part is already there and it needs to be updated (if necessary). * we don't need to implement our 'bail-out' method in install anymore. 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
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
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
[Zope3-dev] Re: zc.buildout: When is recipe.install run?
On Sep 12, 2006, at 9:03 AM, Martijn Faassen wrote: ... The 'svn update' usecase is the reason we could think of why install is always called, even if recipe and buildout config hasn't changed. Right now the install method can be called in a number of different cases: a) when the part isn't there yet b) when the part is there, and the configuration or recipe has changed. In this case the part is removed again automatically, so this is equivalent to a). c) when the part is there, and the recipe and configuration have not changed. In this case there needs to be code that bails out if the part is there and looks okay, or alternatively update code that updates the part (svn up). Case c) looks different. If there was an update method that got called in case c), the install method wouldn't need to be called anymore, and: * the install method can *always* assume the part isn't there and that it needs to freshly install it. * the update method can *always* assume the part is already there and it needs to be updated (if necessary). * we don't need to implement our 'bail-out' method in install anymore. Let me mull that a bit. 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: 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
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
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
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 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
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: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
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
[Zope3-dev] Working on the 3.3.0rc1 release
I'm assuming that the branch is stable and ready. I only ask because a fix was just checked in. If I need to wait, please let me know asap. 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 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] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Benji York wrote: Martijn Faassen wrote: [snip] What do you think about a 9 month release cycle? If we can't manage a 6 month cycle, 9 months is the longest release cycle I think is acceptable. Agreed. I'd like to avoid longer than 9 months too. Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) I think that this is an edge case of time-based releasing: the absolute minimal work we need to do to make a time-based release is to release the trunk. Hopefully we'll be doing more than the minimal amount of work, and we'll actually fix some bugs before we release the trunk. A release can be a good opportunity to fix lingering bugs, after all. Of course with eggification of Zope 3, 'releasing the trunk' is going to be less meaningful in the future... 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] Working on the 3.3.0rc1 release
Hooray! Jim Fulton wrote: > > I'm assuming that the branch is stable and ready. I only ask because a > fix was just checked in. If I need to wait, please let me know asap. I think there is nothing going on that can't wait until after the release. I also wanted to state something that I verified against assumptions that Benji, Philipp and I had yesterday: Going into RC-Mode means that only *release critical* fixed should go into the branch. Nothing else. We have a one week time timout, if no release critical bug turns up, the RC goes out. If any change happens to the RC, we can't release it as final, but have to put out another RC. Jim, are those the rules that apply? We all just kind of derived them from our knowledge. 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
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] Working on the 3.3.0rc1 release
On Sep 12, 2006, at 11:05 AM, Christian Theune wrote: Hooray! Jim Fulton wrote: I'm assuming that the branch is stable and ready. I only ask because a fix was just checked in. If I need to wait, please let me know asap. I think there is nothing going on that can't wait until after the release. I also wanted to state something that I verified against assumptions that Benji, Philipp and I had yesterday: Going into RC-Mode means that only *release critical* fixed should go into the branch. Nothing else. We have a one week time timout, if no release critical bug turns up, the RC goes out. If any change happens to the RC, we can't release it as final, but have to put out another RC. Jim, are those the rules that apply? We all just kind of derived them from our knowledge. Sounds good. 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] Working on the 3.3.0rc1 release
Hi, Jim Fulton wrote: > > On Sep 12, 2006, at 11:05 AM, Christian Theune wrote: > >> Hooray! >> >> Jim Fulton wrote: >>> >>> I'm assuming that the branch is stable and ready. I only ask because a >>> fix was just checked in. If I need to wait, please let me know asap. >> >> I think there is nothing going on that can't wait until after the >> release. >> >> I also wanted to state something that I verified against assumptions >> that Benji, Philipp and I had yesterday: >> >> Going into RC-Mode means that only *release critical* fixed should go >> into the branch. Nothing else. >> >> We have a one week time timout, if no release critical bug turns up, the >> RC goes out. >> >> If any change happens to the RC, we can't release it as final, but have >> to put out another RC. >> >> Jim, are those the rules that apply? We all just kind of derived them >> from our knowledge. > > Sounds good. Alright. Then this is a small reminder to Yusei, that the 3.3 branch has been tagged for RC candidate and only *very critical* changes are allowed to go there until we do 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] Working on the 3.3.0rc1 release
Hi again, Christian Theune wrote: > Hi, > > Jim Fulton wrote: >> On Sep 12, 2006, at 11:05 AM, Christian Theune wrote: >> >>> Hooray! >>> >>> Jim Fulton wrote: I'm assuming that the branch is stable and ready. I only ask because a fix was just checked in. If I need to wait, please let me know asap. >>> I think there is nothing going on that can't wait until after the >>> release. >>> >>> I also wanted to state something that I verified against assumptions >>> that Benji, Philipp and I had yesterday: >>> >>> Going into RC-Mode means that only *release critical* fixed should go >>> into the branch. Nothing else. >>> >>> We have a one week time timout, if no release critical bug turns up, the >>> RC goes out. >>> >>> If any change happens to the RC, we can't release it as final, but have >>> to put out another RC. >>> >>> Jim, are those the rules that apply? We all just kind of derived them >>> from our knowledge. >> Sounds good. > > Alright. > > Then this is a small reminder to Yusei, that the 3.3 branch has been > tagged for RC candidate and only *very critical* changes are allowed to > go there until we do the release. Actually it's just a HEADSUP, I misread one checkin message. So, please be aware that there is going to be a tag very soon and then the rules stated above apply. 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
[Zope3-dev] 3.3.1 release planning
Hi there, I understand that the 3.3.0 release is coming out next week. As the 3.3.1 release manager volunteer, I ask everybody to do the following: If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch first, and then forward port it to trunk. The goal here to make sure we fix bugs in 3.3 after the release. We're planning the release for Zope 3.3.1 release for the first week of october, unless something urgent comes up that necessitates a bugfix release before then. 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] Re: 3.3.1 release planning
On Sep 12, 2006, at 11:56 AM, Martijn Faassen wrote: Hi there, I understand that the 3.3.0 release is coming out next week. Hopefully, that depends depends on how the release candidate goes. As the 3.3.1 release manager volunteer, Yay! I ask everybody to do the following: If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch first, and then forward port it to trunk. The goal here to make sure we fix bugs in 3.3 after the release. We're planning the release for Zope 3.3.1 release for the first week of october, unless something urgent comes up that necessitates a bugfix release before then. Cool. as Christian pointed out, please defer non critical bug fixes until after the final 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] Working on the 3.3.0rc1 release
Hi. At Tue, 12 Sep 2006 17:43:27 +0200, Christian Theune wrote: > Then this is a small reminder to Yusei, that the 3.3 branch has been > tagged for RC candidate and only *very critical* changes are allowed to > go there until we do the release. Oups, Sorry I missed the announcement. I'll be more careful in the future. Thank you. -- Tahara Yusei [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release schedule for Zope 2.11/3.4?
Hanno Schlichting wrote: What do you think about a 9 month release cycle? Based on the Plone experience I think this is a good compromise, between release often and stable releases. The Plone experience as I see it is that we get some measure of contribution fatigue. Take Plone 2.5 and 3.0. With the cycles of review bundles (similar to Zope proposals and discussions), development of new features, bug fixes, merging to alphas, releasing betas and rcs, we found that we basically had to get started on 3.0 just as (if not before) 2.5 final went out the door. That's pretty exhausting. People pull together on bugdays and their spare time to get a particular release out, and then they are being hounded for the next release already. In other words - 6 months is a really short time, especially if you expect to have a reasonable alpha and beta cycle where things stabilise. And further, it's very hard to get people to work on two releases simultaneously (polishing x whilst starting on x+1). I agree that 9 months is a better compromise. 12 months is a very long time. The other important thing is to manage scope - let people know quite early what is and what isn't in scope for a particular release and set clear, agreed-upon timelines for things like proposal deadlines, feature freezes, and alpha/beta releases. Just my opinion, of course. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Benji York wrote: Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) What good could that possibly do? For the people who are not spending their days reading checkin messages, something that is called a final release is a promise that the features they get have been tested and are considered stable, that they can rely on a certain degree of backwards compatibility, and that they're going to get burned. Releases are externally-facing things. They benefit people other than the core contributors the most (the core contributors mostly get the gratification of having released something, and then probably go on playing with trunk). The quality those people receive must be the most important factor by which a release is judged. .0 releases of Zope (2) have had a somewhat negative image before (to the point where people were afraid to let Plone depend on a Zope release that didn't have a .1 or .2 release out already), which I think is getting better. Undoing that would be to the detriment of how people perceive the quality of our software. By the same token, we could just never have releases and expect everyone to live off svn trunk. The idea of a release *cycle* is surely that it's cyclical: at the beginning, we worry about features and innovation, at the end we worry about stability and polish. If the timelines are worked out correctly, then time-based releases help us manage scope and keep moving at a pace that doesn't mean we have enormous mountains of features that take an infinite amount of time to stabilise and get ready. That's a good thing, but ignoring the end-result quality argument by being slaves to the Great Roadmap that was set out six months ago isn't. It's very waterfall. :) Martin (pardon any hyperbole) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:06 +0200: > ... >You got it backwards ;) I only forward-port any changes from older >branches to the more recent ones, but never do any backports. The reason >I do this is because before this, Plone developers tended to only fix a >bug on the trunk or the latest stable release. My hope was that by >lowering the bar by only requiring developers to fix a bug on the oldest >maintained release branch, more people would actually do this and in >fact I think this strategy has worked out. This works in conjunction >with our quite well-maintained bug-tracker where bugs get assigned to >the release they should be fixed in by a small group of people. A very good approach! Because all modifications done on released branch should be fixes only, we want almost all of them in the trunk as well. And there is a good chance that there will only be few merge conflicts. Unfortunately, I could not convince my colleagues to work this way -- despite a good practical experience. One argument has been: the Zope development does not use it... >But two things to keep in mind that differentiate Plone from Zope3 in >this regard are, that most of the fixes in Plone are template issues or >minimal changes that apply cleanly on the newer branches and when they >don't or I do not understand them I ask the bug fixer to forward port >it. You can of course do this always. > ... >For Zope3 the only sensible option IMO is, as others already mentioned >it, to have a fix-on-the-oldest-maintained-branch-first bug fixing >policy which requires to forward port these fixes to all branches up to >the trunk. Why are you that pessimistic about Zope3 -- once the moving around has stopped (which might be a challenge for automatic forward merging)? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 3.3.1 release planning
Martijn Faassen wrote: Hi there, I understand that the 3.3.0 release is coming out next week. As the 3.3.1 release manager volunteer, I ask everybody to do the following: If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch first, No, please fix it in Zope 3.2 first. As far as I understand it, this is the rule now. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:18 +0200: > ... >> Yes. We don't have a Hanno for Zope 3. > >And even if there would be someone willing to do this job, a good >understanding of most of the internals would be a prerequisite, as >merging something which you do not understand is indeed potentially >extremely harmful. The number of people that have a deep understanding >of most internals of Zope3 is fairly limited and I think their time is >better spent on fixing the bugs in the first place. I am merging Zope modifications into our locally maintained Zope version since about 1998. Lots of merges took place without me even knowing that something happened and without any need to understand things. Of course, there have been occational problems and then I had to get local understanding to fix things. In the Zope3 forward porting case, we can instead ask the fix author to do the port instead. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 3.3.1 release planning
Hi, I had an interesting comment from Chris McDonough on a variation how to handle the RC. Instead of blocking changes to the maintenance branch, we could create a temporary RC branch that only the release manager allows checkins to. In this scenario, the maintenance branch stays open for non-critical bugfixes without penalties to other developers. Christian Jim Fulton wrote: > > On Sep 12, 2006, at 11:56 AM, Martijn Faassen wrote: > >> Hi there, >> >> I understand that the 3.3.0 release is coming out next week. > > Hopefully, that depends depends on how the release candidate goes. > >> As the 3.3.1 release manager volunteer, > > Yay! > >> I ask everybody to do the following: >> >> If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch >> first, and then forward port it to trunk. The goal here to make sure >> we fix bugs in 3.3 after the release. >> >> We're planning the release for Zope 3.3.1 release for the first week >> of october, unless something urgent comes up that necessitates a >> bugfix release before then. > > Cool. as Christian pointed out, please defer non critical bug fixes > until after the final release. -- 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 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] Re: Release schedule for Zope 2.11/3.4?
On Tuesday 12 September 2006 07:56, Jim Fulton wrote: > On Sep 12, 2006, at 5:47 AM, Andreas Jung wrote: > > Hi all, > > > > since we are three month late with the current releas, it would > > make sense > > to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If > > we want to stick with the half-yr cycles, we need to schedule the > > next release > > for around March/April next yr. Thoughts? > > We were hoping two switch to May and November. I'd be for May for > 2.11/3.4. +1 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
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
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
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
[Zope3-dev] Re: 3.3.1 release planning
Philipp von Weitershausen wrote: Martijn Faassen wrote: Hi there, I understand that the 3.3.0 release is coming out next week. As the 3.3.1 release manager volunteer, I ask everybody to do the following: If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch first, No, please fix it in Zope 3.2 first. As far as I understand it, this is the rule now. Good point, I was mixing it up in my mind. Who is the Zope 3.2.x release manager? 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] Re: 3.3.1 release planning
Martijn Faassen wrote: Philipp von Weitershausen wrote: Martijn Faassen wrote: Hi there, I understand that the 3.3.0 release is coming out next week. As the 3.3.1 release manager volunteer, I ask everybody to do the following: If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch first, No, please fix it in Zope 3.2 first. As far as I understand it, this is the rule now. Good point, I was mixing it up in my mind. Who is the Zope 3.2.x release manager? Me :) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Martijn Faassen wrote at 2006-9-12 14:44 +0200: > ... >> The current CHANGES.txt from the trunk just lists one new feature (added >> by myself). That's does not deserve a major release. > >It's the nature of time-based releases, though. If nobody does anything >in 6 months, does that mean we won't have a release at all? Of course! Why in hell should you make a release with nothing relevant in it? Both the release process are well as the upgrade process entail a considerable amount of work. You do it only if it is worth the effort. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.3.0 rc1 released!
The Zope 3 development team is proud to announce Zope 3.3.0 rc1. Zope 3 is the next major Zope release and has been written from scratch based on the latest software design patterns and the experiences of Zope 2. Cleanup of the Zope 3 packages has continued to ensure a flexible and scalable platform. We continued the work on making the transition from Zope 2 to Zope 3 by making Zope 2.10 use even more of the Zope 3 packages. But we're not there yet. **You can't run Zope 2 applications in Zope 3.** Downloads - http://zope.org/Products/Zope3 Installation instructions for both Windows and Un*x/Linux are now available in the top level README.txt file of the distribution. The binary installer is recommended for Windows. Zope 3.3 requires Python 2.4.1 to run. You must also have zlib installed on your system. Most Important Changes Since Zope 3.2 - - Provided a new component registry API that allows multiple component registries to be combined more flexibly than before. See 'zope.component.interfaces.IComponentRegistry' for more information. - Greatly simplified local-component registration. See 'zope.component.interfaces.IComponentRegistry' for more information. - Moved many packages out of zope.app to make them easier to use outside of Zope. - Change the session credentials plugin to make it configurable in which fields it looks for the credentials. - Added a new API for collating text. You can now adapt a locale to 'zope.i18n.interfaces.ILocales.ICollator'. You can then use that to sort strings, such as menu entries, in a locale-specific fashion. - A new 'zope.annotation.factory' helper function that makes it easier to create annotations. Also added a README in 'zope.annotation' which explains how to use it. - Added a more complete set of widgets for fields that use iterable sources. These widgets now mirror the set provided by vocabulary-based fields. - Added a cleaner and more robust API to testbrowser for setting file-upload data. - Deprecated several ZCML directives: * factory * vocabulary * content (as an alias to the class directive) * modulealias * renderer:renderer - The 'browser:layer' directive and the 'ILayer' interface has been deprecated. Registering layers has become obsolete, layers should be created as interfaces extending 'IBrowserRequest'. - The 'browser:skin' directive has been deprecated. Skins should be created as interfaces extending 'IBrowserRequest' and can be registered using a simple 'utility' directive. - The 'ISkin' interface has been renamed to 'IBrowserSkinType'. For a complete list of changes see the 'CHANGES.txt' file. Resources - - Zope 3 Development Web Site: http://dev.zope.org/Zope3 - Zope 3 Dev Mailing List: http://mail.zope.org/mailman/listinfo/zope3-dev - Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope3-users - IRC Channel: #zope3-dev at irc.freenode.net Acknowledgments --- Thanks goes to everyone who contributed. ___ 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
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
[Zope3-dev] Re: Working on the 3.3.0rc1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TAHARA Yusei wrote: > Hi. > > At Tue, 12 Sep 2006 17:43:27 +0200, > Christian Theune wrote: >> Then this is a small reminder to Yusei, that the 3.3 branch has been >> tagged for RC candidate and only *very critical* changes are allowed to >> go there until we do the release. > > Oups, Sorry I missed the announcement. > I'll be more careful in the future. You didn't miss it: the announcement of the freeze came out about 15 minutes after your last checkin on the 3.3 branch. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBxyp+gerLs4ltQ4RAnwxAJsEtK3uFfS9/U09R0d7Jj+2l79H/gCgopZ4 guoewgIgKoQUpb9iJSokokw= =di8m -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release schedule for Zope 2.11/3.4?
Hi. Martijn Faassen wrote: > Andreas Jung wrote: >> --On 12. September 2006 13:06:05 +0200 Martijn Faassen >> <[EMAIL PROTECTED]> wrote: > >> Another point with this whole half-yr release cycle: we're going to >> confuse >> more and more professional users about which Zope version to use for >> what. >> I've heard from my major customer but also from other ppl. IN December >> we would have *three* maintained versions 2.9, 2.10 and 2.11. We >> definitely >> can't deprecate Zope 2.9 in December because this version is required >> by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate >> from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for >> the >> mid-future. So my personal impression right now is: we're flooding the >> community with new major releases and the community does not adapt those >> releases. My theory: a major part of the ppl running Zope are running >> Plone. >> on top of Zope...so with have to deal with this fact somehow. As Plone was mentioned as a an argument for scheduling releases, I should probably explain our current release strategy. Similar to Zope 2.8 we had a Plone 2.1 release that took more than 18 months to complete. After that we aimed for the next release (called 2.5) to ship six month after that. Here we tried to copy the new Zope release schedule. But while we tried hard to get a release out in time, we did not succeed with it and ended up with a 9 month release cycle. Now we again aimed for a release six month after 2.5 but we had to adjust our roadmap already and right now we aim for another 9 month release cycle. > That is a good argument for lengthening the release cycle. (as opposed > to say, people will fix more bugs if the release cycle is longer) > > What do you think about a 9 month release cycle? Based on the Plone experience I think this is a good compromise, between release often and stable releases. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Martijn Faassen wrote: Andreas Jung wrote: Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow. That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer) What do you think about a 9 month release cycle? If we can't manage a 6 month cycle, 9 months is the longest release cycle I think is acceptable. Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 16:55:31 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) I think that this is an edge case of time-based releasing: the absolute minimal work we need to do to make a time-based release is to release the trunk. Hopefully we'll be doing more than the minimal amount of work, and we'll actually fix some bugs before we release the trunk. A release can be a good opportunity to fix lingering bugs, after all. I am thinking since one hour about how to reply to Benji's proposal. It's not much acceptable. Major release have to be planned to a certain degree and must be tested (as good as we can) - means we must have alpha and beta releases. Everything else does not make sense to me. Zope 2 is not a kindergarten project and we use it for professional projects and we as a community should act (somewhat) professional. You can of course make daily snapshots available but most developers are using SVN checkouts and professional users don't want depend on snapshots - they expect official releases. Andreas pgp0MBvxjRcPa.pgp Description: PGP 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] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: I am thinking since one hour about how to reply to Benji's proposal. It's not much acceptable. Major release have to be planned to a certain degree and must be tested (as good as we can) - means we must have alpha and beta releases. I wasn't proposing we do away with alphas or betas. More concretely: I was simply wondering aloud about doing "true" time-based releases. On a certain date we cut the first alpha, on a certain date we cut the first beta, etc.. Of course, there must be /some/ flexibility to deal with ultra-critical bugs, but we already do something similar with how we treat release candidates. I believe that the trunk is good enough to produce a release at (almost) any given time. If bugs are known and unfixed when we do a release, we document them (they likely already exist in the previous released version, so we're not doing any harm there). Again, this is all from my Zope 3 perspective, I'm not immersed in the Zope 2 world, so these ideas may not be applicable there. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
