Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-13 Thread Lennart Regebro

On 9/12/06, Jim Fulton [EMAIL PROTECTED] wrote:

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 toblock the release.


Ah. Well, that procedure definitely can get improved on. :)
I think it is imperative that we mark bugs according to the
seriousness so that you know which bug should be worked on first.

I note that the Zope3 collector has the categories medium, low,
critical, 3.3 release and 3.4 alpha 1. I don't think that's a good
idea, but I understand that the Zope collector has no field for
planned release, and those options make sense for features. :-)

Anyway, for me it's like this:

A blocking/critical bug is a bug that means the system or part of the
system gets unusable. It has no workarounds, and affects most users of
the system. Say, PUT_factory suddenly stops working, meaning that FTP
and WebDAV no longer works.

A serious/medium bug is a bug that is a big problem for many users and
has no workaround, or affects everybody, but has a workaround. For
example, that XML import/export didn't work: Workaround, use the non
XML-import/export.

A minor bug is a bug that affects few users and has a workaround, or
has no workaround but only is a problem in very extreme edge
usercases. For example...euhm, ehhh, I can't think of one right now.

(and a trivial bug is not an actual problem for anybody. Could be
spelling errors or ugly design.)

A bug should be assigned a category and stay there. It should not get
it's category changed so not block a release, because if you can do
that, well, then it wasn't blocking in the first case.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Martijn Faassen

Hi there,

Thanks for doing this work, Christian. I'm in favor of going for Zope 
3.4 on a timely basis.


Concerning the delay of Zope 3.3, I think we should consider whether 
we're not too perfectionistic.


On the one hand core developers seem to be happy to use the trunk for 
development projects, and on the other hand we demand a lot of work 
doing bugfixes in a release, up to the point where we delay the release 
itself. That's a bit paradoxical - evidently the bugs aren't harmful 
enough to harm these developers much most of the time, but at the same 
time we consider them extremely harmful if they should appear in a release.


What about a policy where we fix bugs until the release date, and then 
on the release date, we actually release? Any bugs that are still in it 
are going to go with it.


Anyway, if the Gnome project can do time-based releases *on the date* we 
should be able to do it too.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Lennart Regebro

On 9/12/06, Martijn Faassen [EMAIL PROTECTED] wrote:

What about a policy where we fix bugs until the release date, and then
on the release date, we actually release? Any bugs that are still in it
are going to go with it.


I totally agree. My feeling is that the x.x.0 release this time will
be at least as stable as a x.x.1 release normally, maybe even more
stable. Of course, it's bad to have to release a x.x.0 release to find
bugs, but not enough people outside the developer world will actually
install a beta or RC for that to be realistic.

Remember: If all the tests pass, it's ready for a release! :-)

Also, it seems to me that slippage is worse because we slip until we
slip into vacation, which makes us slip even more. I even have the
feeling that people go It's xmas soon, Iäll fix it then and of
course you end up sleeping through xmas and eating too much instead of
programming. I know I do. :)

So, I'm more for a March/September cycle for these reasons.

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote:


Hi there,

Thanks for doing this work, Christian. I'm in favor of going for  
Zope 3.4 on a timely basis.


Concerning the delay of Zope 3.3, I think we should consider  
whether we're not too perfectionistic.


On the one hand core developers seem to be happy to use the trunk  
for development projects, and on the other hand we demand a lot of  
work doing bugfixes in a release, up to the point where we delay  
the release itself. That's a bit paradoxical - evidently the bugs  
aren't harmful enough to harm these developers much most of the  
time, but at the same time we consider them extremely harmful if  
they should appear in a release.


What about a policy where we fix bugs until the release date, and  
then on the release date, we actually release? Any bugs that are  
still in it are going to go with it.


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


I can think of a number of ways to approach this problem:

1. Do less frequent releases.

2. Feature freeze the trunk until the previous release has made it to  
release candidate status


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.


4. Get more volunteers.

These are just some ideas. But something has to give and I don't  
think it should be responsible bug fixing prior to release.


Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Martijn Faassen

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.


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. 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. I call that 
perfectionistic.


I think we have been blocking this release with a selection of bugs that 
included quite a few that weren't absolutely critical. 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 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, and we won't get twice the volunteers either. I think the 
same amount of people will start fixing bugs the same amount of time 
before the release. You could say we get less overhead with more 
releases so people would be able to free up more time to work on the 
release, but on the other hand if a release cycle takes longer the more 
chance is that people will get out of the habit of fixing bugs.


A longer release cycle may help a bit for complicated feature work, but 
I don't think it'll help there a lot too, because if a new feature 
cannot be written and mature in the space of 6 months, it has no 
business being in the core yet anyway.


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.

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.



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.


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?


Who or what would have been hurt exactly had Zope 3.3 been released in 
june? 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.


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.


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.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread 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 

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Christian Theune
Morning,

Martijn Faassen wrote:
 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. 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. I call that
 perfectionistic.
 
 I think we have been blocking this release with a selection of bugs that
 included quite a few that weren't absolutely critical. 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.

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.

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. 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 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, and we won't get twice the volunteers either. I think the
 same amount of people will start fixing bugs the same amount of time
 before the release. You could say we get less overhead with more
 releases so people would be able to free up more time to work on the
 release, but on the other hand if a release cycle takes longer the more
 chance is that people will get out of the habit of fixing bugs.
 
 A longer release cycle may help a bit for complicated feature work, but
 I don't think it'll help there a lot too, because if a new feature
 cannot be written and mature in the space of 6 months, it has no
 business being in the core yet anyway.

I agree on this reasoning.

 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)

 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.

Jup. And I share the hopes that eggification will make that easier.
Together with this, I think that our roadmap should layout not only the
dates when releases happen, but what we *think* will be part of the
feature set.

I'm very split about doing releases on a timely manner without any
features in it. There seems no point.

On the other side I do agree to favor smaller releases instead of
extending the feature develepment period.

E.g. does it make any sense to release Zope 3.4 without the
eggification? It seems to be the only major feature except from bug
fixes, minor features and restructuring.

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

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Christian Theune
Hi,

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

Do we have a list of all (semi-)active committers that we might
brainwash to be a little bit more active? :)

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

 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.

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.

 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.

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.

 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.

Me too. Seems like an agreed point.

 and we won't get twice the volunteers either.
 
 No, but it will halve the work for the small existing group of volunteers.

Only if the volunteers are qualified enough. 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
- if decisions that need to be done are put in there immediately

Sometimes it feels to me that when Stephan or you prioritize a bug that
you have a rough understanding of the solution, and it would be really
great if you could put in a small draft of the solution you imagine. I
think that would be helpful to bugfixers.

 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?

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.

 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.

Can't remember exactly, but I think I did too.

 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.
 

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


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.

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.


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.

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.

...

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.


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

Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Martijn Faassen

Jim Fulton wrote:


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

[snip]
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 know, but perhaps we need to be a bit more aggressive. Christian
Theune's point about empowerment to defer a bug may be useful. We may be
a bit too fearful sometimes to defer bugs right now.


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 think it contributed, though fully agreed it isn't the only source of
the delay.


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.


*Ignoring* bugs is unacceptable. Explicitly deferring a bug for months 
is acceptable, as there are always more bugs than we can fix, and we 
should fix the bugs of the highest priority. A low-priority bug may 
therefore languish. I'm not saying we are doing this correctly *now*, 
but such would be a reasonable process.



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.


Good point. Going through the bugs fixed over the last period makes them 
seem all important to me or alternatively, lesser important bugs fixed 
by the reporter themselves. Perhaps a hard-headed release manager who 
will say important schrimportant and defers the issues anyway would've 
been useful.


Still:

http://www.zope.org/Collectors/Zope3-dev/553

http://www.zope.org/Collectors/Zope3-dev/576

http://www.zope.org/Collectors/Zope3-dev/540

http://www.zope.org/Collectors/Zope3-dev/530

http://www.zope.org/Collectors/Zope3-dev/537

http://www.zope.org/Collectors/Zope3-dev/583

http://www.zope.org/Collectors/Zope3-dev/534

Some issues were only discovered way after we should've done the 
release. We've been

fixing these as part of the release process. All of these issues appear
to be reported after mid-july or later, though. I  think those are good 
bugfix release candidates, and shouldn't have been blocking our 3.3 
release (not all of them are marked critical, but these all have been 
fixed):


http://www.zope.org/Collectors/Zope3-dev/677

http://www.zope.org/Collectors/Zope3-dev/675

http://www.zope.org/Collectors/Zope3-dev/676

http://www.zope.org/Collectors/Zope3-dev/679

http://www.zope.org/Collectors/Zope3-dev/674

http://www.zope.org/Collectors/Zope3-dev/683

http://www.zope.org/Collectors/Zope3-dev/681

http://www.zope.org/Collectors/Zope3-dev/683

http://www.zope.org/Collectors/Zope3-dev/682

http://www.zope.org/Collectors/Zope3-dev/680

http://www.zope.org/Collectors/Zope3-dev/673

http://www.zope.org/Collectors/Zope3-dev/690

http://www.zope.org/Collectors/Zope3-dev/696

http://www.zope.org/Collectors/Zope3-dev/691

http://www.zope.org/Collectors/Zope3-dev/697

Since these all were reported in july or later, we couldn't possibly 
have fixed them if we'd have released in june. :)



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.


Gratefully acknowledged.


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.


I do not believe this to be necessarily the case. The list of bugs fixed 
that were reported after our supposed june release is one reason why I 
think that. The other reason is that there'd be two times as much space 
between bugfixing rounds, which will make bugs languish and people get 
out of the habit of fixing them.



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 

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread 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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development




signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 8:57 AM, Jim Fulton wrote:

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.


I mean I disagree very much. Sigh.

Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread 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. 

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 9:50 AM, Martijn Faassen wrote:


Jim Fulton wrote:

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

[snip]
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 know, but perhaps we need to be a bit more aggressive. Christian
Theune's point about empowerment to defer a bug may be useful. We  
may be

a bit too fearful sometimes to defer bugs right now.


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 think it contributed, though fully agreed it isn't the only  
source of

the delay.


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.


*Ignoring* bugs is unacceptable. Explicitly deferring a bug for  
months is acceptable, as there are always more bugs than we can  
fix, and we should fix the bugs of the highest priority. A low- 
priority bug may therefore languish. I'm not saying we are doing  
this correctly *now*, but such would be a reasonable process.



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.


Good point. Going through the bugs fixed over the last period makes  
them seem all important to me or alternatively, lesser important  
bugs fixed by the reporter themselves. Perhaps a hard-headed  
release manager who will say important schrimportant and defers  
the issues anyway would've been useful.


Still:

http://www.zope.org/Collectors/Zope3-dev/553

http://www.zope.org/Collectors/Zope3-dev/576

http://www.zope.org/Collectors/Zope3-dev/540

http://www.zope.org/Collectors/Zope3-dev/530

http://www.zope.org/Collectors/Zope3-dev/537

http://www.zope.org/Collectors/Zope3-dev/583

http://www.zope.org/Collectors/Zope3-dev/534


None of these blocked the release.




Some issues were only discovered way after we should've done the  
release. We've been
fixing these as part of the release process. All of these issues  
appear
to be reported after mid-july or later, though. I  think those are  
good bugfix release candidates, and shouldn't have been blocking  
our 3.3 release (not all of them are marked critical, but these all  
have been fixed):




Since these all were reported in july or later, we couldn't  
possibly have fixed them if we'd have released in june. :)


But these didn't cause us not to have a release in June.  These were  
reported by beta testers.  Why should
people test betas if we aren't going to address the problems they  
report.  If you aren't going to fix problems reported in beta  
releases, then you shouldn't have beta releases. If you don't have  
beta releases then the .0 releases are beta releases and the ,1  
(hopefully) become the closest thing to final releases and we barely  
do those.  In any case, the final release is delayed.




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


I do not believe this to be necessarily the case. The list of bugs  
fixed that were reported after our supposed june release is one  
reason why I think that. The other reason is that there'd be two  
times as much space between bugfixing rounds, which will make bugs  
languish and people get out of the habit of fixing them.


Well, if we slow down the number of features introduced, then,  
hopefully, the software will stabilize and there will be fewer bugs  
to fix.




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.


-1


Why, do you think we should allow old bugs to languish forever?


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.


So why were these critical issues? What happened during triaging?


They 

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread 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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development




signature.asc

Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


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


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,


This is just common sense.


figuring out what release
is immanent,


But we have a release schedule/


what the repository status is, ...


What does this mean?



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


So what?  Come on, this isn't rocket science.


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.


Want a degree?



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.


Then again, sometimes people just need to apply common sense.

Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:

- I think we want a release manager.


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


What happened after you snapped? :)


You became the release manager. Welcome aboard!


Does the application of irony indicate that we (I) should get over it
and ignore the problem (for now)?


No, only that talk is cheap.  I apologize for the irony.  This talk  
of  just release whatever we have on date X no matter what shape  
it's in and ignore all the other issues we have puts me in a ornery  
mode, the best side of which is irony.



Do we want to find a way how to go
without a release manager?


No.


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.


I'm happy to discuss solutions.  I've mentioned some ideas.  I just  
can't accept a fixed release schedule that sacrifices quality.



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


Yeah, but not now.

Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Christian Theune
Hi,

Jim Fulton wrote:
 
 On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
 - I think we want a release manager.

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

 What happened after you snapped? :)
 
 You became the release manager. Welcome aboard!

Can I make you my assistant? Do I get free health care?

I might get argued into doing that, if the contract that is put on my
head states clearly what my tasks are. If the tasks are unclear, I won't
do it. I'd be happy to help with clearing up the tasks, but I would need
a jump start from someone else (Philipp, Stephan, Jim?).

 Does the application of irony indicate that we (I) should get over it
 and ignore the problem (for now)?
 
 No, only that talk is cheap.  I apologize for the irony.  This talk of 
 just release whatever we have on date X no matter what shape it's in
 and ignore all the other issues we have puts me in a ornery mode, the
 best side of which is irony.

I hope I didn't argue for that because I don't think we should sacrifice
quality.

 - 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?
 
 Yeah, but not now.

I'll put this in my tickler file to raise it again if nobody else does.

Christian

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




signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Martijn Faassen

Hey,

Jim Fulton wrote:
[snip]

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.


-1


Why, do you think we should allow old bugs to languish forever?


I think this would be a bad thing to do after every release, though you 
could do it for a release once every while, I guess. Volunteer effort in 
one area doesn't transfer necessarily to volunteer effort in another 
area, though. You'd block contributors who were interested in moving the 
trunk forward, or force them to do it on their own branch.


[snip]
I think such a larger audience needs to grow organically and has 
fairly little to do with the bugfixing issues.


We disagree.


Okay, to make it clear:

a) I believe that getting timely releases with new features out can help 
grow the audience for Zope.


b) I believe that having high-quality .0 releases can grow the audience 
for Zope.


c) I believe Zope 3 trunk at arbitrary points in time is already a 
fairly high-quality release even without significant bugfix work being 
done, thanks to the focus on quality in the development process. People 
developing their applications against the trunk appear to share this 
opinion.


d) I believe that doing bugfix releases can show a commitment to quality 
 better than not doing bugfix releases.


timely feature releases, high quality .0 releases, bugfix releases, they 
all contribute. My opinion is that timely feature releases are more 
important in growing an audience than high quality .0 releases, for the 
reason that people need to actually do significant work with .0 releases 
to run into bugs, and thus are not entirely new audience (unless .0 is 
seriously botched and doesn't actually work - that's a worst case 
scenario I discuss below). I believe that new people who run into bugs 
would not be pushed away from Zope 3 very much if it was clear to them 
bugfix releases happened regualrly.



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.


Who is we? Why would we have been hurt?


Because the first beta release wasn't even tested by the person who made 
it.  Critical bits were missing.  If we had released it as a final 
release, we would have looked like fools.


What about releasing it as a rc1? That's what release candidates are 
for. Even if we'd have made it .0 (which is not what I'm suggesting), we 
would've looked like fools only until we fixed it in a quick .1 release 
with a self-deprecating message.


Even if such a badly broken beta would've gone out (which I was not 
suggesting, obviously we do *some* testing), we could've done a bugfix 
release.


It would have been a major embarrassment.  I don't know if you've 
noticed some recent threads, but Zope 3 has some serious credibility 
issues in the larger world.


The larger world being Chris Withers? :) Do threads on zope3-dev count 
as 'the larger world'? Perhaps I missed some thread.



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


To whom?


To pretty much everyone who pays any attention to what we're doing.


That's not many people, so no biggie. Let's try to get more people to 
pay attention to what we're doing first. :)



What if we'd have followed up with bugfix releases?


And what makes you think we'd to that well.  If we can get the first 
release so badly botched, what makes you think people will evenbother 
with later releases.


Again, going with the hypothetical worst-case scenario where we made a 
completely botched release:


* Because I bother with trying later releases if a current release of 
software doesn't work.


* Because the window in which we'd release the buggy release and fix the 
bug would be small, and people get the latest bugfix release when they 
download.


* Because linux distributions have packagers who put in the bugfix 
release instead of the botched release, so that many people don't even 
see the botched release.


* Because many people on windows try windows installers anyway, and the 
person making the windows installer would see the brokenness.



What about demonstrating we can release when we say we will?


Releasing crap on time is not acceptable to me.


So the state of the trunk in june was, in your evaluation, crap in june?


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.


Let's do more bugfix releases. I don't think they can be avoided anyway.


Agreed.  Who's going to do it?  Who's going to fix the bugs?


Let's work on a plan so we're going to do this.

Given such a plan, and assuming clear instructions are available, I 
volunteer to make the Zope 3.3.1 bugfix release.



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Stephan Richter
On Tuesday 12 September 2006 10:13, 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.

Right, I just look for bugs that sound like anything serious and not just a 
wish. When I tag a bug as critical or for a certain release, I am basically 
telling the bug fixer to look at it and evaluate whether it needs to be 
fixed. Jim has often overturned my status settings of bugs, and that is 
perfectly fine.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:


Hi,

Jim Fulton wrote:


On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:

- I think we want a release manager.


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


What happened after you snapped? :)


You became the release manager. Welcome aboard!


I was kidding.


Can I make you my assistant?


I'd be happy to make the actual releases (tar balls and windos  
installers) if someone else would do everything else.
Of course, this could be multiple people.  I'm not interested in  
nagging people. I'm happy to help set schedules, but I'd be happier  
not to be in charge.



I might get argued into doing that, if the contract that is put on my
head states clearly what my tasks are. If the tasks are unclear, I  
won't
do it. I'd be happy to help with clearing up the tasks, but I would  
need

a jump start from someone else (Philipp, Stephan, Jim?).


I'd be happy to come up with a minimal list, but I'm sure you'll  
think of tasks I won't.


Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Christian Theune

Jim Fulton wrote:
 On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:
 Jim Fulton wrote:
 On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
 - I think we want a release manager.

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

 What happened after you snapped? :)

 You became the release manager. Welcome aboard!
 
 I was kidding.

I know. So Martijn and I both stepped forward a small bit on this. So we
need some conflict resolution. :)

I acknowledge the importance of the task and I'd do it, but I don't want
to put down anybody who is enthusiastic about it.

 Can I make you my assistant?
 
 I'd be happy to make the actual releases (tar balls and windos
 installers) if someone else would do everything else.
 Of course, this could be multiple people.  I'm not interested in nagging
 people. I'm happy to help set schedules, but I'd be happier not to be in
 charge.

I understand that.

 I might get argued into doing that, if the contract that is put on my
 head states clearly what my tasks are. If the tasks are unclear, I won't
 do it. I'd be happy to help with clearing up the tasks, but I would need
 a jump start from someone else (Philipp, Stephan, Jim?).
 
 I'd be happy to come up with a minimal list, but I'm sure you'll think
 of tasks I won't.

That would be nice. I'm putting up a todo for myself to come up with
tasks, I'll also investigate if we have any material on zope.org that
already describes this.

Christian

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




signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Dieter Maurer
Martijn Faassen wrote at 2006-9-12 11:25 +0200:
 ...
On the one hand core developers seem to be happy to use the trunk for 
development projects, and on the other hand we demand a lot of work 
doing bugfixes in a release, up to the point where we delay the release 
itself.

core developers probably have other means than simple Zope3 users.

When you see some problems simple Zope2 users have, you
may understand that they should not be bothered with bugs in
addition...



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Jim Fulton


On Sep 12, 2006, at 1:24 PM, Christian Theune wrote:



Jim Fulton wrote:

On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:

Jim Fulton wrote:

On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:

- I think we want a release manager.


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


What happened after you snapped? :)


You became the release manager. Welcome aboard!


I was kidding.


I know. So Martijn and I both stepped forward a small bit on this.  
So we

need some conflict resolution. :)


Let Martijn do 3.3.1. Why don't you do 3.4.

I'd be happy to come up with a minimal list, but I'm sure you'll  
think

of tasks I won't.


That would be nice. I'm putting up a todo for myself to come up with
tasks, I'll also investigate if we have any material on zope.org that
already describes this.


I think that the making a release information is pretty good, as far  
as it goes.


Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Roadmap for Zope 3.4

2006-09-12 Thread Christian Theune
Hi there,

Jim Fulton wrote:
 I know. So Martijn and I both stepped forward a small bit on this. So we
 need some conflict resolution. :)
 
 Let Martijn do 3.3.1. Why don't you do 3.4.

Actually dividing that job up to different people, maybe on a kind of
rotation, sounds like a good plan. What do you think? I'd be more than
happy to take over a release every now and then. This has multiple
advantages:

- more people will know how this works
- it's easier to get people in and out
- nobody has to commit for a very long time.

 I'd be happy to come up with a minimal list, but I'm sure you'll think
 of tasks I won't.

 That would be nice. I'm putting up a todo for myself to come up with
 tasks, I'll also investigate if we have any material on zope.org that
 already describes this.
 
 I think that the making a release information is pretty good, as far as
 it goes.

I'll read that again. I'm more interested in the stuff that should be
done before the release.

Christian

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




signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com