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

Re: Staged Freezes

On Sat, 13 Nov 1999, Chris Leishman wrote:

> On Fri, Nov 12, 1999 at 11:02:25PM -0500, Brandon Mitchell wrote:

> > I'd propose 2 things, the developer says they want their package
> > considered for the current proposed dist, and second, the transfer from
> > the pool to the proposed is done using the bug tracking system and a
> > delay.  The delay is to give time for old bugs to be closed and new bugs
> > to be opened, say a week.  Given no open bugs and a developer desiring to
> > move the package to proposed, then do it automatically.
> > 
> Ok...this sounds a little better - but I still think this has some flaws.

[ sorry for retabing, you ran off my screen ]
> 1) We are relying alot on developers to know when is a good time to move
> their packages to the "proposed" dist - which is alot to ask since most
> of us wont be running the proposed dist ourselves to be testing on.  I
> would think that the majority of developers only have one machine they
> develop on, which naturally runs unstable.  To build and test packages
> on this platform and then hope that they work on the "proposed"
> distribution would be error prone. 

Basically, you always want your package to go into the current proposed
unless you have good reason to think otherwise.  For example, you know
bugs will still be open (this saves a script the time to check), you
haven't finished a reorganization, or it's just a quick debianizing of a
large program that still needs lots of work to finish the package.
Basically if the owner doesn't want it in proposed, then neither should
anyone else, and we shouldn't start abusing the bug tracking system to add
the "functionallity".

> From my observation, most developers would run the distribution they are
> working on - they keep their machine running unstable until it freezes,
> then keep running frozen until it stabilises.  At that point everyone does
> the final update and goes "wow - it a new stable distribtuion" before they
> do apt-get dist-upgrade to the new unstable.

I do agree that this allows packages with weird interactions to make it
into proposed.  If this occures, it's sure to be noticed quickly because
there are more eyes that expect something with fewer bugs than what is
currently in unstable.  Once noticed, the offending package can be yanked,
maybe replaced with something from stable.  An updated package goes into
the pool, lots of people probably test it because they want the newer
version and not that thing from stable, and the bug list is updated

> 2) Bug reports.  A delay is all very well to ensure there are no open bugs,
> but as I have just stated, this in no way ensures that it wont have bugs
> in the "proposed" distribution.

First a clarification, it's only RC bugs that we are worried about.
Second, there will always be bugs.  I think the above explains how to
significantly decrease what we know about.

> 3) This idea makes it extremely hard to do "base" upgrades (say a new libc).  
> At what point do you move the base system to "proposed", since it will
> probably break everything in there?  And we cant just leave it till later
> on, as no new packages will be able to go into "proposed" as they wont have
> the support of the new base there.

This is when you would create a new empty proposed area and separate pool.
It doesn't need to be mirrored by everyone (mirror maintainers take a sigh
of releif).  People can easily test the results of your work.  Starting
empty means you quickly know what is left to do.  The current
pool/propsed still goes on while you are working and your goal is to get
your stuff as the next release.

> 4) You still have to freeze the proposed at some point.  Debian really does
> need to have a static, tested "stable" distribution (not only for CD's, but
> so people know exactly what they will get when they install a stable
> distribution).  In fact - most of the servers I look after reference debian
> distributions by their codename (hamm, slink, potato) - so that I know 
> exactly which code base I'll be pulling stuff from - no matter what happens
> to their stability state.

Yes, you still freeze.  But now the freeze is for something like 2 weeks. 
Not only that but developers can still work on non-freeze things in the
public, should they desire (their work goes into the pool).  Everyone
turns on any test box they to make sure it is working correctly.  When you
start doing it every 3-4 months, things will get routine, which is how a
freeze needs to be. 

> 5) Are there going to be enough people testing "proposed"?  
> <snip>
> > People still download what they want, actually there would then be 3
> > instead of 2 levels, stable, proposed, and pool.  Any bugs in proposed are
> > quickly backed out of.  The pool is the developer and tester area.  The
> > proposed is another tester and update-happy user area.  Leaving stable
> > where it always was, boring and proven, the way it should be.

As you just quoted, yes, I believe so :-)  These are the developers that
don't want any headaches, and everyone else that always tries frozen after
it's been a few weeks.  I believe there are quite a few people in both

> Hmm...I still don't like the idea of a perpetual unstable "pool".  At the
> moment developers basically work to stabilise the distribution _they are
> running_ (see earlier point).  We find a bug and we fix it because we know
> that will make the system more stable.  But I really don't want to live with
> the thought that at any point in time the system will break horribly under
> me (see next point before telling me that unstable is meant to be like that).

You would be a likely candidate for following the proposed area instead of
the pool.  What we could use is a tool that makes this really easy to do,
with the addition of following specific packages from the pool.

> As it is, I'm not a developer that updates to the new unstable immediantly
> after frozen goes stable.  I don't have the time or resources to deal with the
> major changes that usually go on at the start of the unstable development
> cycle.  So I wait until it has settled down a bit first - then I upgrade.

I don't think you are alone.  I'm similar, except I upgrade to frozen a
few weeks after it goes.  This is mainly because of my lack of machines,
bandwidth, and my role in the -testing group.

> This idea fits into my staged development model - by giving people a definate
> idea when things will be at certain points of the cycle.  I am happy to move
> to a system after the base has "frozen" but when the librarys, etc are still
> under active development.

I admit there is merit to your system.  I do have 2 questions.  First,
where do updates to your packages go when your area is frozen?  The more
open everyones work is, the better in my opinion.  Second, how is your
implemented?  For my system, it would be a program/script that looks at
the date a package is uploaded, the flag a maintainer uses to mark a
package for proposed, and a poll of the bug count.  When all three are ok,
move the package.  During a freeze, comment that line out from cron.  I
also would like to see the wave effect of lots of changes in a short time
decreased.  In my system, those people that do a last minute upload must
wait a week before making it into proposed, and when a bug is found, you
just missed the release window and you'll have to wait until next time.
It can be a real quick way to break that habit.

> I think one thing people are missing is the fact that alot of hard to resolve
> RC bugs are because an individual package has internal problems, but by they 
> way they fit in with the rest of the distribution.  The model I propose aims
> to aleviate this by giving each stage of the development cycle an unchanging
> base upon which to build - reducing the chance of inter-operation problems.

Yes, but would you say this is a minority of the overall number of bugs in
unstable/frozen?  My gut feeling says they are.  The pool system leaves
you with few internal package bugs, and maybe some intra-package bugs.
The current system has so many internal package bugs that it's takes over
most peoples effort during the freeze.  The staging system would decrease
both types of bugs, but I don't how much it will be.

> <snip> 
> > Goal setting results in longer freezes and periods between freezes.
> > Playing catch-up and the desire to see something cool motivates most
> > people.  Goals can still occur, they just can't hold everything up.
> > Across the board changes can still occur, they just move to a different
> > proposed area.
> I really disagree with this.  Goal setting is _not_ going to result in longer
> freezes.  It is the lack, or unattainabilitay, of a goal that causes problems.
> This _is the point_ of my model - to make the goals more obvious and 
> obtainable.

Ok, let me take a step back here.  My comment was against the current
setup and not against the staging system.  The problem with goals is that
it's easy to push things off til the last minute, we all do that.  Both of
our systems eliminate the problem of poor goal decision.  However, would
you be willing to extend a freeze for a package so it can get in the
current release?  If so, you run the risk of doing the same thing we have
now.  Otherwise, we don't differ much on this point. 

> PS. Sorry for the long email!

heh, beat ya.

Actually I should probably do a formal proposal of how it works,
implemented, etc so we are talking about the same thing.  I'll see if I
can work up some time.


    Brandon Mitchell  *  http://public.surfree.com/bmitch  
  bmitch@surfree.com  *  ICQ: 30631197  

Reply to: