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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
