[Zope3-dev] Roadmap for Zope 3.4

[Jim Fulton]

On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:

> Jim Fulton wrote:
>> On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote:
> [snip]
>>> Anyway, if the Gnome project can do time-based releases *on the  
>>> date* we should be able to do it too.
>> Maybe they have more volunteers.
>
> Yes. They also have a *lot* more to release. Their release story is  
> also massively more complicated than ours. And they release, on the  
> day they say they will release. It's too easy to say they do this  
> because they had sufficient amounts of volunteers.

All I know is that we don't have enough volunteers.  Too few of us do  
way too much of the work,


>> I don't think our problem has been perfectionism.  I think our  
>> problem has been a lack of will to fix things in a timely manner.
>
>> One problem we have is getting things to be tested.  It hardly  
>> motivates people to test for and report bugs if their reports  
>> don't affect he release.
>> I think we have a serious problem that needs to be addressed.  I  
>> don't think the right way to address it is to release despite  
>> known serious bugs.  Note that some judgement goes into  
>> considering whether a bug is serious enough to block a release.   
>> We don't block a release for just any bug.
>
> Before a release, bug triaging needs to take place.

Which we do.

> I recall you saying we defer bugs too often and bugs never get  
> fixed, so we should stop doing any feature work until all bugs are  
> fixed, etc.

We should. We have yet to do this.  As I mentioned in another note,  
we should prevent new features at the beginning of a release cycle  
until we've caught up on past bugs.

Trying to address old bugs was not responsible for the delays in the  
3.3 release.

> I call that perfectionistic.

Then your idea of perfection and mine are far apart. Letting bugs  
languish for months or even years is not acceptable.  Ignoreing bugs  
reported during beta testing, when we get too little testing to begin  
with is unacceptable.


>
> I think we have been blocking this release with a selection of bugs  
> that included quite a few that weren't absolutely critical.

Name a few.

>> I would suggest we triage bugs a lot more aggressively instead. I  
>> say this as someone who spent a few afternoons staring at Zope 3  
>> bugs trying to get them out of the way.

I've spent way more than a few afternoons.


>> I can think of a number of ways to approach this problem:
>> 1. Do less frequent releases.
>
> I do not believe this helps a lot for bug fixes. If we have twice  
> the release period, people won't start fixing bugs twice the amount  
> of time in advance,

Right. This, alone is not a solution.

> and we won't get twice the volunteers either.

No, but it will halve the work for the small existing group of  
volunteers.

>> 2. Feature freeze the trunk until the previous release has made it  
>> to release candidate status
>
> You mean don't branch the trunk (and thus let it be the release  
> branch) until the release has made it to release candidate status?

Yes.  I think it is a shame to have to do this, but I think this is  
now necessary.

I would go further.  I would not unfreeze the trunk until until we've  
cleaned up all open bugs, either by fixing them or rejecting them.


...

>> 3. Release less.  I think it's time to start thinking of some sort  
>> of "core" Zope 3 that we can manage with the very limited number  
>> of volunteers we have now.
>
> +1, though I wonder how much this has been blocking the release -  
> important bugs that could block releases don't tend to be in out of  
> the way components, one would think.

I spent a lot of time on crap that wasn't core at all.


>> 4. Get more volunteers.
>
> Getting a release out is *difficult* and the amount of volunteers  
> available, while important, is only partially related. More  
> volunteers won't speed it up tremendously much and can even slow  
> things down. Plone has many volunteers and has had much problems in  
> the past doing timely releases. Silva has had far less volunteers  
> and can do more agile releases, because there's less people to manage.

And because it is much smaller.  I think we're far from having too  
many volunteers on Zope 3 maintenance.  I'm
not optimistic that we'll get more volunteers, which is why I'm  
inclined to release less.

>> These are just some ideas. But something has to give and I don't  
>> think it should be responsible bug fixing prior to release.
>
> Large Zope 3 projects have been working against 3.3 for many months  
> now. If there was any absolute showstopper in Zope 3.3, why have  
> these projects successfully transitioned?

It all depends on how large you want the audience to Zope 3 to be.  A  
small community on a limited number of platforms can work around well- 
known problems.

> Who or what would have been hurt exactly had Zope 3.3 been released  
> in june?

Well, we would have been hurt badly as the first beta release, the  
one made at around that time was badly broken.

There were some serious bugs.

We would have demonstrated pretty clearly that we don't care about  
quality.

> I don't think it's Zope 3's reputation that would've been hurt, as  
> Zope 3.3 in june was not *that* buggy. Bugfix releases are also a  
> completely accepted practice.

Except that we don't do much of those and we put little effort into  
the ones we do do.

> I still think our quality standards for a release have been too  
> high. Getting people to fix more bugs is good, sure, but perhaps we  
> should separate this at least somewhat from the release itself.

Sorry, I agree very much.  I'd be willing to defer to a Zope 3  
release manager, if there was one.

> If we're going to do timebased releases, we should have a button  
> somewhere that says 'make a release', and a date on which the  
> button is pressed. If the release is botched, we can press the  
> button again for bugfix releases, and we have 6 months in which to  
> do a better job next time.

IMO, that would be a disaster.

If we're going ti do time-based releases, we need to have a realistic  
schedule and the necessary commitment to meet that schedule.  Right  
now, we have neither.

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