[Zope3-dev] 3.1 Timeframe

[Jim Fulton]

Martijn Faassen wrote:
> Stephan Richter wrote:
> 
>> On Friday 04 March 2005 15:24, victor at itfreedom.com wrote:
>>
>>> Hello, I was wondering if the fine Zope 3 folks could give me a rough 
>>> idea
>>> when the general 3.1 release might come out?  I mean, when the currently
>>> available source would be considered ready to be called such.
>>
>>
>> This depends totally on how fast the outstanding bugs will be fixed; 
>> there are several non-trivial serious ones. Once all the bugs have 
>> been fixed and XXX comments addressed one way or another, Zope X3.1 
>> will go into beta. Theoretically, this could be next week, but my 
>> experience from the X3.0 release tells me it will be more of the time 
>> scale of 2-3 months.
>>
>> I wish I could give you a much narrower date range, but the community 
>> is currently too small to make sound predictions.
> 
> 
> We realize that the extreme length and unpredictability of this release 
> process seems rather odd to you, so I'll try to offer some explanation 
> about what I believe to be the underlying causes. I'll also explain how 
> you can help speed it up.
> 
> Besides lack of resources, the length and unpredictability is due to 
> certain quality assurance features and requirements of the Zope 3 
> release process.

These are *not* going to change, although the XXX situation is somewhat
special. I'll discuss it below.

 > Besides being resource intensive by themselves, these
> requirements also discourage the contribution of further resources that 
> could speed up matters.

If quality standards are a deterent to some contributors, then so be
it. I'd rather not have those contributions.

> If you feel inclined to contribute to the release, note that it is not 
> possible to get an overview of all outstanding things that need to be 
> fixed (this contributes to the unpredictability of the process).

That's not correct. You can go to the collector and find things to do.

 > What
> you need to do is grep the Zope 3 source for the character combination 
> "XXX", read the comments there, and probably ask the programmer who 
> checked in the "XXX" for an explanation about what ought to be done.

Right.

1. We need to avoid checking in XXXs to the trunk or release branches.
    These represent technical debt that should appear on the trunk only
    in extreme cicumstances.

2. If someone checks in an XXX, it should be
    up to *them* to clean them up.  It isn't reasonable to ask someone to
    contribute by cleaning up someone elses XXXs.

3. In the interest of getting 3.1 out the door, I'd be willing to either
    allow some XXXs to get into 3.1, or convert them to colector issues.
    I *do* want to get 3.1 out as soon as I can, however, I personally don't
    have tome to contribute much to it now.  (I have tight customer deadlines
    and am trying hard to get Zope 2.8 out in what spare time I have.)

A major reason why this release is taking so long is that the current
primary contributor, Stephan, embarked on a large, disruptive, and
*extremely valuable* project that took much longer than he expected.
I'm not about to fault him for this as I greatly appreciate the nearly
thankless effort he has put in to clean up this part of the code.

We're all interested in getting 3.1 out as soon as we can, given other
constraints.  We agree that, after this release, we want to adopt
a regular frequent release cycle.  We decided to adopt such a release
cycle too late to affect 3.1.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org