[Zope3-dev] Roadmap for Zope 3.4

[Christian Theune]

Hi,

Jim Fulton wrote:
> 
> On Sep 12, 2006, at 8:58 AM, Christian Theune wrote:
> ...
>> Ack. One thing that bothers me (and it's totally possible that I'm
>> missing some documentation from zope.org) is that the overall process
>> isn't well documented, so it's hard for me (and probably other people)
>> to jump in and do stuff.
> 
> Um.  I'm sure that it could be clearer, but how complicated is it really?
> You fix the bug on the release branch, including updating CHANGES,txt,
> merge the change to the trunk, and resolve the issue.

I was more referring to the selection of bugs, figuring out what release
is immanent, what the repository status is, ...

>> Right now I *feel* like only Stephan and Jim know how to triage bugs and
>> that I'll do something that won't be right.
> 
> Huh?  There's no magic or special expertise involved.

Obviously no magic, but not needing special expertise is something you
can't derive by looking at what you do. Especially as priorities are set
without a comment. And I think you do apply reasoning, and everybody
reasons a bit different (also widely the same too).

>> I probably could just go
>> forward, but I have a bad feeling about my knowledge about the process,
>> and I don't want to feel bad, so I don't do it. (Which makes me feel
>> just slightly bad because I didn't do anything. ;) )
> 
> I think you are making this harder than it really is.

I've been training a long time to make things as hard as possible.

> FWIW, I use the following approach:
> 
> - Early in the process, I mark every real reproducable bug as blocking.
>   In this last go around, this included a number of bugs that had been
>   around for months or years.
> 
> - Later in the process I downgraded lots of bugs because I didn't want to
>   block the release.
> 
> If people report bugs during beta testing, I think it's important to
> resolve
> the bugs reported, otherwise, why should people bother testing.  If
> people aren't going to test, then why have beta releases.  Why should
> anyone use Zope if we don't bother testing it.
> 
> ...

Alright. That's good for me to know. I can judge bugs based on that. I
just need that one tiny explicit piece on what to apply.

To almost quote David Allan: When people want to do work, they shouldn't
have to go to the 'thinking about how to do work'-mode because that will
put them in a state of uncertainty which disallows any actions.

>>>> 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?
>>>
>>> +1. Keep things focused on the release during the release cycle is
>>> useful.
>>
>> Right. In addition to that, I'd love to have a single "status" page (a
>> bit like Mozilla has) that says:
>>
>> - Zope 3.2 is in maintenance mode, please make sure bugs are ported
>>   to this release.
>> - Zope 3.3 is in release mode (beta).
>>   Please fix bugs until XXX. No features allowed.
>> - The trunk is frozen.
>>
>> (Or whatever information is appropriate at a given point in time)
> 
> Sounds great.  I'm sure one of our copious volunteers will make it happen.

I know. :(

*sigh.

I know I can't step forward. I wonder if there is a way to implement a
community effort to avoid having to have some individual to commit to a
maintenance task?  Otherwise anything we come up with that requires
maintenance will be a no-go.

>> +100 for the button. (A huge wiki page on how to do a release does *not*
>> account for a button)
> 
> I can't think of a civil response to this, so I'll just hold my tongue.

:(

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/4fd0451f/signature.bin