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
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
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 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. Regards, Martijn
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
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
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.) > > 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'd help to get this work out in the hands of the people. Very few people understand what he's done exactly and why it's good as there are not a lot of people who know or care much about the innards of the component architecture. Still, understood. > 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. Yes. I am paying so much attention to this issue because: a) I think we can significantly improve on the track record of Zope releases of the last year or two. Releases don't happen very frequently, and release dates are set which aren't kept, repeatedly, causing people to lose trust in release schedules (or alternatively release dates are left so vague nobody can plan at all). I want to avoid this with Zope 3, but I see signs of this pattern already happening. b) I think it'll help Zope 3 significantly. c) I think I have experience in the process of releasing software. It involves managing scarce resources (developer resources are *always* scarce). It involves lots and lots of decisions to make do with imperfection. Zope 3's focus on quality is great, awesome, but compromises are essential to get this software into the real world. Everybody knows this, but it can't hurt to give this some extra weight in the somewhat rarified circles of Zope 3 development. :) Regards, Martijn
RSS Feed