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

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  
-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?  
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  
 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 
-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.  
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  
-Tier 2 ports aren't dropped. They are just slower, and don't provide all  
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  
version with the feedback received.  

DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

Reply to: