[Lalo Martins <lalo@webcom.com>] Re: Summary of Thread: "Releases"
(I forwarded this to debian-devel, as you did allowe it. Jens).
------- Start of forwarded message -------
From: Lalo Martins <lalo@webcom.com>
Subject: Re: Summary of Thread: "Releases"
To: debian-private@lists.debian.org
On Mar 09, Jens Ritter decided to present us with:
>
> [Note: This is anonymized from posts to debian-private and to be crossposted
> to debian-devel within 24 hours! Please send corrections!]
Any comments I made on this thread, or any comments I make from
now on, can be quoted or forwarded outside -private.
Also, Knghtbrd is writing his version of the propsal, you might
want to wait for that.
> 3) using "promotion" only for the first steps in the release cycle and
> the current release process for the finalization (stable/CD snap
> shots).
>
> 4) #3 with a detached "release team" completely in charge of the move
> from frozen to stable (release team only has rights to freeze, do
> NMU's to frozen, will release official cd's, etc.)
Huh? I never saw anyone propose otherwise. There is no sense in
using the promotion mechanism at unstable -> frozen, and even
worse frozen -> stable. The promotion is only for the case
holding -> unstable.
And how could freezes/releases be implemented without a release
team (or as you say, #3 without #4)? If there is any way to do
that you may list as a separate proposal, but I don't see one.
I think these two are a core part of the proposal.
> Arguments in favor:
The original proposal was by Bdale, and his favourite argument
in favour was not listed. My words:
- packages that are not ready for release just never get
into frozen, so they don't hold the release off. It has
been mentioned (by Bdale) that the idea that taking a
snapshot of "unstable" is the path for ever making it
"stable" doesn't make the slightest sense.
> Arguments against it:
>
> - more people make the process more opaque and this makes the
> survey of the process impossible.
It depends. With specialization, as someone else proposed (the
release team is composed of small teams as it is now, with very
specific functions, and representatives from the other
architetures), I don't see how this would happen.
> - what about dependencies?
As far as my proposal goes, package "a" can't be promoted
holding -> unstable if some of its dependencies are still in
holding. Also, it must be possible to have different versions of
a package in holding and unstable at the same time.
Finally, if there is a "frozen" dist at the moment, the only way
a package can make unstable -> frozen is by action of one of the
groups that comprise the release team (qa, I'd guess).
> - what about different architectures? How to get them in sync?
> (proposers think this can be solved, but did not provide
> arguments).
I also don't see what makes this problem different than what we
have with the current upload/release system. As someone (Bdale?)
mentioned, the sollution (both for the proposed system or the
current one) is to allow different versions of packages to
coexist in the source archive.
It is possible that the release team make it a rule that nothing
can be included in frozen if not all released architetures are
in the same version. But as I don't see the problem, this is
only my best educated guess at a sollution.
> - BTS has to track bugs by release and/or package number (=>
> rewrite, who will do this?).
Not "has". Better "should" or "would be nice"... but the current
BTS versioning system works perfectly with the new proposal
(bugs are closed as soon as a package is uploaded to holding).
A BTS review (don't know if "rewrite" is mandatory, having never
looked at the sources) is already necessary; the current bug
versioning system doesn't help the architetures problem.
> - another reorganization of the archives.
Huh? No. A reorganization of rules. Uploads start to go to
"holding". Burden on the dupload team is lightened. Slink
remains at "stable". Potato is renamed "holding", an "unstable"
directory is created and we start promoting things into there.
When the release team decides to freeze it, a directory "potato"
is created and "ln -s potato frozen". All packages in unstable
are symlinked into frozen, and the qa group and the testing
group (and even maintainers) start removing those symlinks if a
package is too buggy for frozen. What reorganization?
> - esp. #4 puts high load on release team if it is small.
There is no release team.
(define 'release-team (+ qa-group testing-group
representants-from-porting-groups boot-floppies-team CD-team
project-leader perhaps-more-I-dont-remember-now))
Or in english: "release team" is just a collective term for a
lot of people with very specialized tasks.
> Instead look into these issues:
>
> - current release process is not "broken", only needs more
> communications between the involved parties.
Anyone who thinks the release system is not broken is suffering
from a severe case of resistence to change.
> - "release team" must continue work even during non freeze.
These is a proposal that makes some sense but fails to address
the points. I can't imagine how this would shorten the freeze
stage.
> - release has to be kept in mind by everyone.
I have mixed feelings about this.. A lot of us aren't here to
make releases; a lot of us doesn't care to live off anything but
unstable. Not my case; I don't have infinite bandwidth so I can
still use CDs. But one of the points that make working with
Debian so cool is that _you_ choose your level of commitment.
You may maintain one package or two and don't even pay attention
to the lists (except keep an eye on policy changes, which are
announced in devel-announce anyway), or you may subscribe to
almost all lists, be a member of the qa group, technical comitee
and whatnot.
> - corner stones have to be announced clearly.
Huh?
> - cd scripts, bootfloppies and other release critical software
> should be worked upon all the time.
Absolutely correct. But then, AFAIK some of these _are_ worked
upon all the time. The guys are hackers, after all. They _enjoy_
what they're doing.
> My Comments:
>
> I would really like to see Debian adopt some kind of "bazaar" style
> for release --- but without loosing quality. So some kind of mixture
> between the current system and the proposed system is what I would
> like to see.
Detail a proposal and we can discuss it.
I also fail to see where the proposal makes us lose quality.
> But before considering a change first let's dicuss further on how to
> handle dependencies with the proposed system:
>
> What happens if a binary incompatible libc is introduced? How will
> it and packages depending on it be promoted without inflicting the
> state of the "higher" systems (i.e. without degrading the stable
> state)?
Exactly the way we did with hamm, where's the problem? Assuming
we were to move to libc7 now with the new system. A package
"libc6" would continue to be maintained and packages that depend
on it would continue to work. In whatever pace suits them,
maintainers would upload new versions depending on libc7. And
above all, this would have to happen _outside_ a freeze.
[The fact that we call a freeze "freeze" and then when it's
released you can count on your fingers the number of packages
_not_ updated during the "freeze" doesn't make us look too
serious either ;-)]
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux -- http://www.debian.org
--
Please respect the privacy of this mailing list.
To UNSUBSCRIBE, email to debian-private-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------- End of forwarded message -------
Reply to: