On Sat, Nov 13, 1999 at 09:56:14AM -0500, Brandon Mitchell wrote:
> On Sat, 13 Nov 1999, Chris Leishman wrote:
> > On Fri, Nov 12, 1999 at 11:02:25PM -0500, Brandon Mitchell wrote:
<snip>
>
> [ sorry for retabing, you ran off my screen ]
Yes..I noticed the tabbing was stuffed...
(chris now goes and changes muttrc to have editor='vim "+set tabstop=8"')
<snip>
> 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".
This sounds a bit like "experimental" to me...
<snip>
> 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
> appropriately.
Ok. This sounds like a lot of shuffling back and forth in proposed though...
> > 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.
"decrease what we know about"? s/decrease/increase/ I think (we really want
to know about as much as possible don't we?? :)
>
> > 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.
Hmm...this sounds really, really messy. To me, it sounds exactly like forking
the project. Does this mean we will have a debian-libc7, and/or
debian-x11-4.0?? This means every time we have a change that reflects across
the whole system we need to start a whole new pool and then try and coax
developers to develop to it instead? How about policy decisions (like
/usr/doc/ v's /usr/share/doc). Would these also result in a fork?
I don't this this idea recognises or caters for the number of base changes we
actually do have..
> 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.
This is a common aim of both proposals.
>
> > 5) Are there going to be enough people testing "proposed"?
>
> <snip>
> 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
> catagories.
A good point, however, is that we _need_ to have developers in the classes
for the system to have a hope of working. Plus there needs to be _alot_ of
communication back and forth. Another difficulty would be for a developer who
follows the "pool", but has a bug in the "proposed" area...how does he go
about working it out?
>
> > 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.
Oh don't get me wrong. At the moment I like to be at the cutting edge,
because even when there are problems appear, most of them can be resolved
quickly and easily - or I can hold the offending package for a while.
What I don't have time for is the big changes that cause lots of problems -
particularily ones I can't fix. Of course, since your model would require a
new pool when there is a major underlying upgrade, then I guess I could use
the pool happily......
<snip>
> 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.
1) There should be a new "unstable" distribution open up at some point during
the cycle. The timing of this would have to be up to the release manager
(with consideration for timing and mirror space, etc).
You would, perhaps, not open it up until fairly late in the cycle. I don't
think this would be a big problem, as the packages that freeze earlier in
the cycle are the ones that won't be changing very often anyway.
2) Implementation is pretty simple. The install scripts/maintainer simply
processes the group of "frozen" packages in the same way that they
currently do for a frozen distribution. At particular stages (as decided
by the release manager - preferable before the start of the current cylce)
packages are added to this "frozen" list. I haven't looked at it myself,
but I can't see that it would be hard to do at all.
> > 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.
Even if they aren't the minority(?) they are by far the hardest to resolve.
An internal package problem is easy to fix - just bug fix it. However a
inter-operability problem is much, much harder to resolve as it requires
careful co-ordination between maintainers. IMHO this kind of problem gets
even harder if there isn't a firm baseline for people to work to.
<snip>
> 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.
The whole point is to make sure that we don't do silly things like extend
freezes (no offence to the current release team!). If we keep the release
cycle short, then there should be no major problems if a package misses the
deadline. And as you said, people will learn quickly.
Of course - the release manager would still have the discression to let
some stuff through...but it is a discression that should be used very,
very rarely.
>
> > 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.
>
Feel like writing mine up too?? :) I guess I'll try and do so - but maybe
not this week (exams...yay!)
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpxKDem3ThUc.pgp
Description: PGP signature