gmane.comp.web.zope.zope3

victor | 4 Mar 21:20

3.1 Timeframe

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.

(My sincere apologies if I've posted this to the wrong place.)

Thank you,
victor

headers

Stephan Richter | 6 Mar 13:36

Re: 3.1 Timeframe

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.

> (My sincere apologies if I've posted this to the wrong place.)

No, this is the right place for this sort of question.

Regards,
Stephan
--

-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

headers

Martijn Faassen | 9 Mar 10:13

Re: 3.1 Timeframe

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. Besides being resource intensive by themselves, these 
requirements also discourage the contribution of further resources that 
could speed up matters.

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). What

(Continue reading)

headers

Jim Fulton | 9 Mar 16:07

Re: 3.1 Timeframe

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.

(Continue reading)

headers

Martijn Faassen | 9 Mar 17:27

Re: 3.1 Timeframe

Hey,

Jim Fulton wrote:
[snip]
> 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.

If these extreme circumstances exist, it is justified to require this 
person going to the issue tracker and adding an issue. You can also make 
the source so it's easier to find it, but that shouldn't be the only thing.

> 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.

If this is checked into the trunk or release branch, this introduces a 
dependency on that person before a release can be done. In order to 
produce a timely release, you don't want a dependency on people like this.

Anyway, so what I'd propose is that  XXX on trunk or release branches 
should always go with an explicit issue, and that the person merging a 
non-release branch is responsibile for wiping out the XXX before the merge.

> 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.)

(Continue reading)

headers

Christian Heimes | 13 Mar 00:39

Re: 3.1 Timeframe

Jim Fulton wrote:
> 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.

My personal opinion about this:
Finding bugs or edge cases is a way of contributing to open source. 
Sometimes you don't have the time or the knowledge to fix a bug. It's 
better to mark an issue and leave it to others than letting the bug slip 
through.

I agree with you if it's a feature the person wants to have in Zope3. In 
this case the person should either do it himself or pay a developer to 
do it.

Christian

headers

Garrett Smith | 9 Mar 17:10

RE: 3.1 Timeframe

Jim Fulton wrote:
> 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.

I'm one of the silent beneficiaries. The guilt!

Each time I change some deprecated code I appreciate the cleanliness of
the new component regime/organization. This indeed was a huge
improvement -- and the work was herculean, including all the BBB code.

MUCH appreciated Stephan!

 -- Garrett