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 -