[Zope3-dev] 3.1 Timeframe

[Martijn Faassen]

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