proposal following the "Bits from the release team meeting"
I am no debian developer (At least I am not involved in debian uploads and
releases). I have just followed the discussion, and have nothing to lose,
because I am not part of the community anyway. But I have seen a lot of
wise things said on the mailing list, but not assembled in one text. So if
this can spark discussion for an improved proposal, what ever it might
look like, I will consider this time well spend. :-)
The main questions raised that I have seen:
-What are the problems with the current system of maintaining multiple
architectures?
-Why are all the restrictions imposed by the proposal in "Bits (Nybbles?)
from the Vancouver release team meeting" necessary?
-How should responsibility be divided between package managers, port
teams, and release team?
-How could a work flow look like, that combines stable releases with
timely releases, is dynamic enough to pick up or drop architectures as
needed, motivates both packagers and porters as much as possible (I think
of the "perverse incentives" discussion here), and SCALES, both in
architectures, and in number of packages?
Taking from the proposal "Bits (Nybbles?) from the Vancouver release team
meeting", adding in what sensible thoughts I have read on the mailing
list, and glueing it together with what I think makes sense, I am posting
one possible answer to that last question: How could a possible work flow
look like?
---------------
Neccessities:
1. Categories have to give assurance. Statements along the lines of "All
tier 1 debian architectures are fixed two days after the source was made
available" must be possible.
2. The release team must be able to put pressure on both porters and
packagers, so that release is possible in a reasonable time frame.
3. The release team must have as little to do with individual packages and
individual ports as possible (because both numbers are rising)
------------------the support levels-----------------------------
tier 1:
1. at least 98% of the sources (excluding arch specific) are successfully
built for the arch
2. for stable: All packages build, none contains an RC bug.
3. every new upload is attempted to build after maximally 2 days
(this guaranties that the arch is release ready after a 2 days freeze,
and that every package enters testing after max. 2 days)
4. can guarantie a certain compile speed to get security updates out of
the door fast
(guarantied max time from security source upload to binary for the arch)
5. there must be a working, tested installer
tier 2:
1. 5 developers
2. 50 users
3. machines usable without signing NDA
4. at least 50% of the sources (excluding arch specific) are successfully
built for the arch
5. every new upload is attempted to build after maximally 14 days
6. security updates available after maximally 14 days (if the package is
provided)
7. there must be a working, tested installer
tier 3: no formal requirements (maybe tier 2/ 3.?)
Architectures can change up or down at any time, not only for a release.
Diskspace, tools and bandwith are provided for all tiers, with mirrors as
necessary according to download statistics.
>From the above points: possible assurances:
-All tier 1 architectures cover all packages included in the stable
release
-All tier 1 architectures gain a security fix with the debian announcement
of the vulnerability
-Such announcements can be made very fast (depending only on normalized
compile time)
-All tier 1 architectures update unstable packages with no more then 2
days delay
-All tier 1+2 architectures can be installed in a straight way with the
installation methods provided by debian
-All tier 2 architectures provide a new binary to close a vulnerability no
longer than 2 weeks after the debian announcement.
-All tier 2 architectures update unstable packages with no more then 2
weeks delay
----------------------
Proposed steps to a release:
1. A date is set for the code freeze, and the release.
2. At the date of the code freeze (the point were 0 RC bugs are expected)
all packages still containing arch independent RC bugs are dropped (at the
discretion of the release team a package could still be fixed instead,
moving the release date back)
3. Two days time to let the architectures build remaining packages
4. All tier 1 architectures are determined (lets call them tier 1(F)), for
whom 98% of all packages (excluding architecture specific ones) built, and
don't contain RC bugs. (at this point the release team could again grant
an architecture more time to reach this treshhold.)
5. All packages which have an RC bug in a tier 1(F) architecture are
dropped (with this, every tier 1(F) arch automatically becomes tier 1 for
the stable release)
6. Mirrors obtain the binaries, the release is ready
7. Other architectures can achieve tier 1/2 status later (they just have
to meet the requirements)
While a stable release is maintained, security updates are released after
all tier 1 architectures have compiled binaries. This will obviously take
longer if more/bigger packages have to be recompiled, but should be
roughly equal for all tier 1 architectures, because of their guarantied
compile speed (in whichever way it is achieved).
For the same reason, propagation to testing shouldn't lag.
----------------------------
Consequences:
A port can have different tier status for stable and unstable.
There are no "social requirements" towards the release team. As long as
the architecture meets the requirements, it gets the status automatically.
Only lenience for gaining HIGHER rating is possible.
Hopefully this implementation would achieve the following (please disagree
if you don't think it does!)
-It shoulders the porters with the responsibility to stay in tier 1.
-It shoulders the packagers with the responsibility to stay well supported
within tier 1 or fear to be dropped from a release.
-It leaves the release team the possibility to grant both packages and
arches more time to make it into the release, but this can never be
counted on.
-ports using wanna-build have to empty their "queue" at least every second
day
-Tier 2 ports aren't dropped. They are just slower, and don't provide all
packages.
So the packagers will support closing of bugs in tier 1 ports, because
they otherwise risk not being in the release. The tier 1 ports for their
part will help with all problems specific to their architecture, for fear
of losing their status otherwise. And the high hope is of course that most
architecturs will actually reach tier 1, so they can participate in this
balance. Tier 2 ports have the unavoidable problem, that they won't have
as much support from the packagers, because the packages are not
threatened by them. Hopefully no packager will reject good fixes though...
And with all three tiers sharing the same tools, and having disk space and
bandwith at their discretion, building up a new port would hopefully be as
easy as it can be made. And since tier 2 ports already provide security
fixes, they should be moderately usefull for production environments, and
have a good chance to gain experience, before achieving tier 1.
It can happen that a port temporarily loses tier 1 state in unstable. That
doesn't effect stable at all, but guaranties propagation of packages to
testing within two days.
An "architecture" flag will be needed for package uploads.
-------------------------------
Remaining questions:
Definition of sufficient compile speed? (maybe time needed for some
predefined group of packages?)
The percentages (98% and 50%) are from "Bits (Nybbles?) from the Vancouver
release team meeting". Both they and the time frames (2 days and 2 weeks)
are of course variable without effecting the rest of the proposal.
Any way to provide for better teamwork between tier 2 ports and packagers,
without tying the packagers down?
-------------------------------
Should there really ensue an discussion about this, I will likely post an
updated
version with the feedback received.
Icekiss
--
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
Reply to: