On Fri, 2009-07-17 at 19:55 +0200, Bert Freudenberg wrote:
> On 17.07.2009, at 19:41, Ken Causey wrote:
> > On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
> >> In any case a process where development slows down when nearing a
> >> release would be in order, we might need feature freezes etc. Maybe  
> >> we
> >> simply set a release date now and then work towards it?
> >>
> >> - Bert -
> >
> > I would suggest an alternate model.  Rather than forcing developers  
> > as a
> > group to follow some sort of schedule why not consider a release a
> > snapshot of the development trunk minus some questionable or  
> > problematic
> > updates plus some additional cleanups relevant to a release.
> >
> > Let's say I wanted to create a release today and let's posit that  
> > there
> > are a number of known good updates after Nebraska 14 and 15.  I could
> > update to the update just before Nebraska 14, then manually merge in  
> > the
> > updates afterward.  Then do whatever clean up I want to do.  Then
> > release.
> 
> IMHO that would prolong the problem that the release is not a real  
> community effort. For many years now, the release team consisted of  
> very few people who had to do all the integration work themselves. I  
> feel that this is simply too much of a burden for those individuals  
> (even though they volunteered to do it) and at the same time a much  
> greater sense of a shared product could be created in the community by  
> actually working on that product together.
> 
> I think extending the number of committers is one of the most valuable  
> aspects of the trunk model. It comes along with greater responsibility  
> for all of course, but that can only be good I'd say.
> 
> - Bert -

I don't see why the process of deciding what to remove and what to add
in can't be done as a group.  While my description is clearly a manual
one I don't see that it can't be largely automated and that the
description of what is done could be a joint one among those interested.

Personally I suspect that not all core developers find the details of
individual releases to be all that interesting and are in fact willing
to rely on others with more interest to define them.  I don't wish to
exclude anyone, but at the same time I see no reason why any particular
individual must participate in this part of the process.

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090717/317d5172/attachment.pgp