[Zope3-dev] Roadmap for Zope 3.4

[Christian Theune]

Jim Fulton wrote:
>> 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.

Ah. That's different than what I expected! But I'm alright with it once
I know it.

I totally agree that the process might not be as complex as I imply, but
the thing is that there are places where I *feel* like I'm missing
something. And hidden parts of a process make it seem to be complex. At
least for me. And for some reason, I don't manage to jump into the right
mode everytime and ask for process clarification immediately.

> 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.

Ok, good to know then.

>>>>> 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.

Scheduling some effort for a nice 3.3.1 is more reasonable. Then I'd be
fine with a post-poned 3.4.

>>> 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.

That's not exactly what I meant. How many people are actually
contributing?  I'd like to know if we're talking about 5, 10 or 20 people.

>> - 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.

Well. Almost. My point was to make a small 3.4 release which could
already integrate the features we made on the trunk, so that we don't
get a hunormous release in May.

However, as I get another side effect from this (later deprecation), I'm
fine with some effort one 3.3.1.

>> - I think we want a release manager.
> 
> You're a genius!  I'll just snap my fingers.

What happened after you snapped? :)

Does the application of irony indicate that we (I) should get over it
and ignore the problem (for now)? Do we want to find a way how to go
without a release manager? I don't like agreeing that there is an open
end and than just letting the discussion about it die somewhere. I just
wanted to be explicit.

>> - 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.

New thread then?

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20060912/e0eb2865/signature.bin