[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: My views on release management



Previously Richard Braakman wrote:
> Wichert Akkerman wrote:
> > Previously Richard Braakman wrote:
> > >   * Be loud.  Keep the developer community aware of what is suppposed
> > > to happen when, what the release goals are, and if we're waiting why
> > > we're waiting.  This probably means weekly mails during the
> > > development period, and announcements whenever necessary during the
> > > freeze.
> > 
> > No weekly announces during the freeze?
> 
> I assumed that "whenever necessary" will be more frequently than once
> a week :)  

Okay. Make it `whenever necessary, but at least once every week' :)
 
> I had hoped that you would continue to maintain that list.  It's
> something that can be split off from other release management tasks
> with relative ease.

I'm noticing organizing things and bussiness takes more time right now,
and I fear I'll end up not having enough time to properly maintain that
list. I already feel it deserved more attention during the slink freeze
then I put into it.

> I also think release goals are good, they motivate people and they
> give such warm happy feelings when they are accomplished.  And they're
> an incentive to clean up those last few loose ends.

True, but we tend to set big goals, and if we make them release-critical
we'll never release. We have to be realistic here and consider them
non-release-critical release goals, ie project goals :)

> Our development model requires support for hybrid systems in any case,
> since "unstable" is always updated gradually and most developers run
> unstable.  Witness the libc5 to libc6 conversion.  I have libc5
> support on my system even today.

Hmm, I still seem to have it, but nothing uses it anymore. Oh, I see
there's OSF Motif 1.2 in /usr/local. Oh well..

> > Within limits; this probably needs some further discussion.
> 
> What kind of limits did you have in mind?

At least give a maintainer a couple of days (2? 3 if there's a weekend
in there?) to respond, unless you have a very hard timelimit. I think
the same should apply to the security-team by the way.

> With "create unstable", do you mean freezing?  Then it wouldn't be a
> pre-freeze :) The big difference between freezing and not freezing is
> that uploads won't go into the upcoming release by default during the
> freeze.  And I don't think we can change that; we get more than 100
> uploads per day, and confirming them all manually would drive me sane.

It would drive you sane? good! :)

You can automate that: only demand manual confirm for packages going
into section libs.

> I discussed this pre-freeze idea in more detail in two other mails.
> I'll wait for you to catch up to those :-)

Hmm. I'll see if I can track them down.

Wichert.

-- 
==============================================================================
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: wakkerma@cs.leidenuniv.nl
WWW: http://www.wi.leidenuniv.nl/~wichert/

Attachment: pgp1jbp2E3GrS.pgp
Description: PGP signature


Reply to: