Re: [Zope-dev] Re: Zope 2.9 goals
As I mentioned before, I'd like to see Christian's blob work make it into 2.9. So that's one feature. ;-) On Mon, 2005-06-20 at 09:55 +0200, Martijn Faassen wrote: > Lennart Regebro wrote: > > OK, so becuase of the tomembased release schedule, let's not dicuss > > what goes in 2.9. let's discuss what features we found most > > urgent/desirable, so we can start working on that, like now. > > I think it's fine to discuss what we want to be in Zope 2.9. This way we > can plan for it to actually be there. > > We just should realize that if nobody does the work in time, it won't > actually be in there, but that should only get the pressure up. The hope > is that a time-based schedule will actually speed up feature > development, not slow it down. > > But you're right, work should start soon. This is also why I started the > discussion now. > > Regards, > > Martijn > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Lennart Regebro wrote: OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now. I think it's fine to discuss what we want to be in Zope 2.9. This way we can plan for it to actually be there. We just should realize that if nobody does the work in time, it won't actually be in there, but that should only get the pressure up. The hope is that a time-based schedule will actually speed up feature development, not slow it down. But you're right, work should start soon. This is also why I started the discussion now. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
--On 19. Juni 2005 11:35:32 +0200 Lennart Regebro <[EMAIL PROTECTED]> wrote: OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now. Propose something :-) -aj pgp3DpDmVWBU8.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Jim Fulton wrote: Martijn Faassen wrote: [snip] This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious? Actually, I think that time-based releases make planning fairly easy. There *will absolutely* be a Zope (2&3) feature freeze and beta release November 1 (or sooner if we think that this leaves too little time for a beta cycle). There *will* be a final release in December, come hell or high water. If you think this is to ambitious, then lets move the freeze/beta up to give us more time for bug fixes, say October 1? No, I think the time period for freezes is okay, and you're right, if we take this approach and take care not to destabilize close to the freeze, it should be possible. I'll just stop worrying for now. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
--On 17. Juni 2005 13:17:13 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote: Policy aside, I trust all of these people implicitly to do the right thing with judging whether a feature should make it into a dot release and I wouldn't complain any of them snuck a minor feature into one. If one of them got out of control (that Tim character is a wild-man!), I'm sure somebody would notice and go hose them down. I agree totally. As RM I would have been task to enforce this policy. But because given the fact we had very long release cycles adding new minor feature was acceptable and worked more or less fine - not perfectly but it worked. Otherwise the complete Z2 development would have stand still. So for me time-based releases will only work if people show responsibility and commitment. -aj pgpxpcsIIFHUX.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
On Fri, 2005-06-17 at 13:00 -0400, Tim Peters wrote: > [Tres Seaver] > > Agreed, in theory. In practice, the usual handwave has been to construe > > the absence of the feature as a bug (with greater or lesser justification). > > Like that's going to change . Over the last year Tres, Andreas, Tim, Fred, Jim, Florent, Stefan H., Yvo, Sidnei, Christian T., Chris W., Christian T., Mark, Jens, Brian, Tino, Paul W., Lennart, dunny, and Dieter (by proxy ;-) have all contributed code to Zope 2 one degree or another. Policy aside, I trust all of these people implicitly to do the right thing with judging whether a feature should make it into a dot release and I wouldn't complain any of them snuck a minor feature into one. If one of them got out of control (that Tim character is a wild-man!), I'm sure somebody would notice and go hose them down. If time-based releases prove not to work out, I'd hope we could revert to that sort of common-sense defacto process. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Chris McDonough wrote: On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote: ... We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years. I wasn't aware of this and I don't think it's a good policy. Feature releases should be backward compatible. Bug-fix releases should be for bug fixes. Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification). Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version. Which is just fine IMO. Such an outcome might be "acceptable", but could hardly be called "desirable." I'm not sure what outcome you are refering to. Surely not the "dead-end" of 3.3. I'll note that a *big* pile of potentially useful ZODB features were pretty much inaccessible to the Zope2 community from the date of the first 3.3a1 release, nearly two years ago[1], until the release of Zope 2.8 last month. This timespan, eerily enough, coincides almost exactly with the life of the Zope 2.7 release cycle[2]. Of course, ZODB 3.3 was technically incompatible with Zope 2.7 because it required new-style classes. There's nothing we could have done to make those features accessable sooner short of a major architectural change which, frankly, we could not afford. I know how and why the loss happened (I helped *make* it happen, I'm afraid), but I don't want it to happen again. Moving to time-based releases should help with the problem, but we aren't there yet, Right, we are going there. That's what the discussion is about. We have to start some time. We are going to start in December. We couldn't start for Zope 2.9 or 3.1 because we were already committed to changes that were in and needed time to finish. This won't happen in the future because we know that something can't be checked into the trunk unless it is ready for beta and we know that there will be a definate date for the beta. Anything not in by then won't be in the release. and won't be for a year (a successful delivery in December could be a fluke). This makes no sense to me at all. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
[Tres Seaver] > Agreed, in theory. In practice, the usual handwave has been to construe > the absence of the feature as a bug (with greater or lesser justification). Like that's going to change . > Perhaps we can be more hard-nosed about a "no new features in third-dot > releases" policy *after* we get a timeboxed release process in place? I > have some recollection that a hard-nosed application of such a policy in > ZODB land contributed to the creation of the "dead-end" 3.3 release > line, never incorporated in any released Zope2 / Zope3 version. Various versions of ZODB 3.3 were shipped with various ZopeX3-3.0.0 releases, but ZODB is also used by people who don't run Zope. The latter is why I make "standalone" ZODB releases, which have no dependence at all on Zope. While I have timed ZODB releases entirely based on what various Zopes seem to need, I try to do that in ways that make good sense for standalone-ZODB users too. Starting a ZODB 3.4 for new features (and new deprecations) was necessary for ZODB's "other" users (despite not being crucial for Zope's purposes). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Tres Seaver wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jim Fulton wrote: >> >>> Chris McDonough wrote: >>> >>> On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote: >>> >>> ... >>> >>> We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years. >>> >>> >>> >>> I wasn't aware of this and I don't think it's a good policy. >>> >>> Feature releases should be backward compatible. Bug-fix >>> releases should be for bug fixes. >> >> >> >> Agreed, in theory. In practice, the usual handwave has been to construe >> the absence of the feature as a bug (with greater or lesser >> justification). >> >> Perhaps we can be more hard-nosed about a "no new features in third-dot >> releases" policy *after* we get a timeboxed release process in place? I >> have some recollection that a hard-nosed application of such a policy in >> ZODB land contributed to the creation of the "dead-end" 3.3 release >> line, never incorporated in any released Zope2 / Zope3 version. > > > Which is just fine IMO. Such an outcome might be "acceptable", but could hardly be called "desirable." I'll note that a *big* pile of potentially useful ZODB features were pretty much inaccessible to the Zope2 community from the date of the first 3.3a1 release, nearly two years ago[1], until the release of Zope 2.8 last month. This timespan, eerily enough, coincides almost exactly with the life of the Zope 2.7 release cycle[2]. I know how and why the loss happened (I helped *make* it happen, I'm afraid), but I don't want it to happen again. Moving to time-based releases should help with the problem, but we aren't there yet, and won't be for a year (a successful delivery in December could be a fluke). [1] \ http://www.zope.org/Products/ZODB3.3/NEWS.html#what-s-new-in-zodb3-3-3-alpha-1 [2] http://www.zope.org/Products/Zope/2.7.6/CHANGES.txt Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCswEA+gerLs4ltQ4RAmv6AJ98s+dbAbB81g8lRpcRaDHjcyVpMACgq0Ak GK6MYOUvPrazO5oJDn5xXIo= =1SET -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Chris McDonough wrote: On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote: ... We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years. I wasn't aware of this and I don't think it's a good policy. Feature releases should be backward compatible. Bug-fix releases should be for bug fixes. Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification). Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version. Which is just fine IMO. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Martijn Faassen wrote: Jim Fulton wrote: Max M wrote: Jim Fulton wrote: Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Will they have the same relase date or will they be offset by a few months or something? They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations. This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious? Actually, I think that time-based releases make planning fairly easy. There *will absolutely* be a Zope (2&3) feature freeze and beta release November 1 (or sooner if we think that this leaves too little time for a beta cycle). There *will* be a final release in December, come hell or high water. If you think this is to ambitious, then lets move the freeze/beta up to give us more time for bug fixes, say October 1? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Jim Fulton wrote: Max M wrote: Jim Fulton wrote: Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Will they have the same relase date or will they be offset by a few months or something? They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations. This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.9 goals
Max M wrote: Jim Fulton wrote: Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Will they have the same relase date or will they be offset by a few months or something? They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )