[Zope3-dev] Zope 3 release planning

[Jim Fulton]

Martijn Faassen wrote:
> [moving this to zope3-dev]
> 
> Stephan Richter wrote:
> 
>> On Wednesday 16 February 2005 08:41, Martijn Faassen wrote:
>>
>>>>> You realize that all XXXs must be removed before the release, 
>>>>> right? You
>>>>> were the one who advocated this. :-) Or did you mean a TODO comment?
>>>>
>>>>
>>>> This seems like an entirely reasonable thing to do before the next
>>>> release.  It shouldn't take a volunteer more than an afternoon.  :-)
>>>
>>>
>>> So the 3.1 release will not happen before this has been done by some
>>> volunteer? :)
>>
>>
>>
>> Exactly. Or it is converted to a TODO. The release policy is that the 
>> code must be free of XXX comments for a release. I spent a whole lot 
>> of time (like about 1-2 weeks) removing and converting XXX comments 
>> for the X3.0 release. Not having XXX comments in a release is part of 
>> our quality assurance. 
> 
> 
> So many ways of holding up a release is asking for trouble in my mind. 
> You not only have to resolve issues in the issue tracker (which at least 
> can be deferred to a following release), but have to actually *solve* 
> all XXX issues from the codebase that anyone could've added. The only 
> person I know brave and productive enough to actually do that is Stephan 
> Richter, and Stephan Richter alone does not an open source project make.

There are other volunteers.  Of course, we could use more.

> I think the release process for Zope 3 should focus a bit less on 
> quality assurance and a bit more on actually releasing it. Zope 3 is 
> already much higher quality than Zope 2 ever was or ever will be. But 
> the features are not reaching the developers -- if you want to do a 
> release in the foreseeable future, you should definitely not develop 
> against the Zope 3 trunk.

I don't agree that we should focus less on quality assurance.  In fact
we should focus more.

We also need to focus on getting to regular time-based releases.  To do
that, we need to slow feature work.  We need to only add features
that are of adequate quality and we need to plan this work
based on the release schedule.

Unfortunately, we decided to move toward frequent releases *after*:

- A bunch of new work was done, in doing so, we incured some technical
   dept that really needs to get paid back.

- And a significant time passed without progress on collector issues.

> The only reproducable way I know of to do a release (sort-of) on time is 
> to *ignore* certain issues for the time being and defer them into the 
> future. You can always do a bugfix release, or, since your next release 
> is coming up in a forseeable future, just wait until the next release.
> 
> "Release early, release often" -- Zope 3 is missing out on a lot of 
> opportunities for open source contributions here. People are not going 
> to be attracted to the Zope 3 platform with only a single release out 
> and nothing else in sight.
> 
> Yes, I know I'm sounding like a broken record here.

Especially since I and others already agree with you.  We are going to switch
to regular releases, but it's going to take some effort to get that started.

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