[Zope3-dev] Roadmap for Zope 3.4

[Jim Fulton]

On Sep 12, 2006, at 9:17 AM, Christian Theune wrote:

>> 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 agree on that. However, we have a bad history lurking in the  
> collector
> and I think we should be a bit more forgiving about not fixing old  
> bugs
> immediately (obviously they can't be that urgent) but apply more  
> care to
> the new bugs from testing periods. That narrows the area of focus a  
> bit
> and makes it easier for us to massage them.

Right, that's why none of these blocked the release just because they  
were old.


>>> 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 know a few bugs that weren't important but fixed by me, because I
> wanted to spend some bugfixing time but didn't find any higher  
> priority
> bugs that I could tackle.

That's fine, but they didn't block the release.

> I know that I have been delaying one fix that took me weeks because I
> underestimated the effort. Probably, I should have given a heads-up on
> me beeing stuck there earlier.

Yup.  I think you and I agree that this was a critical bug that  
should have blocked the release.

There was also a ZODB test failure on Mac OS X that I felt was  
critical.  I spent weeks on this.  In retrospect,we should have  
shipped Zope 3.3 using ZODB 3.6, although that too had Mac OS X  
problems.

>>>> 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.
>
> As a contributor, you have the luck to be able to make decisions about
> pretty much everything regarding the code base, where others need to
> rely on comments on the mailinglist because intricate knowledge is  
> missing.

I don't know what this has to do with commit access. I agree that a  
lot of knowledge is often needed, although I worked on a lot of  
shallow bugs that others could have worked on.


> This would mean the requirement for volunteers might need rephrasing:
> We need a sufficient number of volunteers that are familiar enough  
> with
> our process and Zope to make maintenance easier for everybody.

Sure.  I don't agree that the process is that complicated.


>> No, but it will halve the work for the small existing group of  
>> volunteers.
>
> Only if the volunteers are qualified enough.

The volunteers we have now are obviously qualified enough.  If we  
don't get more, we have to give them less work.

> On the other hand, a lot of
> the bugs in the collector would be easier to fix if the
>
> - descriptions and reproducability would be better

Sure, OTOH, it's easy to ask for clarification and to reject the  
issue if a clarification is not forthcoming.
If we did this continually, rather than waiting until just before the  
release, this would be very easy.

> - if decisions that need to be done are put in there immediately

Volunteers are needed to make that decision.

> Sometimes it feels to me that when Stephan or you prioritize a bug  
> that
> you have a rough understanding of the solution,

You are mistaken.  Stephan should speak up on his criteria, but I  
have the impression that it is "guilty until proven innocent".  That  
is, I think he marks everything new as critical and relies on people  
working on bugs to downgrade them.

For myself, I consider the effect of the bug, not the solution.  If I  
have an idea what the solution is, I either note it or assign it to  
myself.

>>>> 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.
>
> See my statement on our bug history. This might be a large but very  
> cool
> one-time effort to get our history cleaned up. We could have one large
> release that is targeted at getting rid of all open bugs. Maybe we
> should do this for 3.4 and put eggification to 3.5?

Or maybe it should be a 3.3.x release and we don't allow any more  
feature work until the collector is cleaned out.  We're actually not  
that far from that as we did make a lot of progress during this last  
cycle.

I do think we should schedule 3.4 for May, not November.

And I think we need to start the beta cycle earlier.  I think the  
beta cycle for a May release should start March 1. I really think  
we're already too late to make a November release.

> I really can imaging having more gocept developers fixing a bug  
> here and
> there if we do that. Weird motivation, but it's easier to communicate.

Cool, get them started now.  We don't have to wait until November to  
get a 3,3,1 release that includes resolution of all the old bugs.


> At least for Zope 3.

Right. That's what I'm taking about.

> I think Zope 2 has a good history of bugfixing
> releases. And we should be able to adopt that. It doesn't seem to be a
> terrible complicated and huge task to release a Zope 2 bugfix  
> release as
> Andreas is doing it all the time.

Um, depends on who's doing it.  It's not a big effort at all if  
you're not doing it.

>>> 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 disagree very much.  I'd be willing to defer to a Zope 3  
>> release
>> manager, if there was one.
>
> I think this should trigger a *red alert*. IIRC Plone had those  
> problems
> until they had started having a rigid release manager. (Which would  
> also
> solve part of the problem of information visibility because that would
> be one obvious person to talk to about process and guidance.)

OK, consider a red alert so triggered.

>> 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.
>
> Ack. We didn't even have a road map written down nor a set of features
> we committed on.
>
> I'm trying to summarize some of the ideas and open ends from my  
> posting:
>
> - What about having a list of all  (semi-)active committers so we can
>   ping them and ask for their assistance?

Um, there's something wrong with this.  So the more someone  
contributes, the more they'll be asked to contribute more?

Anyway, I have a script that I used to determine foundation committer  
nominees. I'd be happy to share this with anyone who wants to nag  
people who already contribute a lot to ask them to contribute more.

> - What about making the point in Zope 3.4 about fixing up our bug
>   history?

Isn't that what bug-fix releases are for?  Why not make that the goal  
of 3.3.1?  Or better yet, let's make this time based!  Let's say that  
all of the bugs in the collector reported as of the final release  
have to be fixed in 3.3.1 one month after the final release.

> - I think we want a release manager.

You're a genius!  I'll just snap my fingers.


> - Make it easier (or make it better understood how) to make releases.

+1 MakingARelease spells it out pretty clearly.  There are a lot of  
issues here that I don't want to bring into this thread.

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