Hello, world, please allow me as a member of the release team to share my view of the issue as I have been invited to the vancouver meeting as well. The contents of Steve's message were meant as a proposal, not as a definite decision and of course any input from you, whether as maintainers, as porters or as debian developers, is welcome. Personally however, I didn't even remotely expect the outcome of this meeting to be what it actually is. Otherwise, I would have discussed about that e.g. with Wouter, whom I saw just before I left for Vancouver. I am sorry that some of you had other impressions.
Please allow me another remark: That meeting didn't finalize the release goals for etch. We talked about some of course - like we do on IRC quite often, but we didn't finalize anything. The only settled difference to sarge is that we need to move GFDLed docu out of main, but that's not our decision, but the result of two GRs of all developers. I was asked quite often via IRC what the reasonings for this kind of proposal were. I'll answer the reasons from the release point of view - but please remember that there are also ftp-masters/mirror concerns that the release team doesn't directly take care of, but which are of course still important. As Steve wrote | The reality is that keeping eleven | architectures in a releasable state has been a major source of work for | the release team, the d-i team, and the kernel team over the past year; | not to mention the time spent by the DSA/buildd admins and the security | team. Considering the experience of the release team, the number of different architectures were _one_ part responsible for release delays - not the only one, and the others need also to be solved. | - the release architecture must be publicly available to buy new that has the reason that the system needs to be "alive". It can't be Debians task to try to keep a dying arch up as long as possible. Of course, there will be a timespan during which an arch is hard to buy, but still useful and somehow available. We should of course support the release during this time which would probably mean one or two releases but does not mean we will be able to infintly support this arch. | - the release architecture must have N+1 buildds where N is the number | required to keep up with the volume of uploaded packages The reason for this proposal should be instantly clear to everyone who ever suffered from buildd backlogs. :) We want that all unstable packages are directly built under normal circumstances and that in the even of a buildd going down the arch does not suffer noticably. The long periods of trying to get some RC-bugfix in while some arch has a backlog should disappear with etch. | - the release architecture must have successfully compiled 98% of the | archive's source (excluding architecture-specific packages) well, that's just an "the architecture is basically working", so that we don't get too many RC-bugs because of architecture-specific issues, and also don't get too many packages kept out of testing for not all archs being built. Of course, the 98% is not engraved into stone, and might just be another arbitrary high number like 97.5%. From looking at the usual level where we start noticing problems with testing migrations, a number in this range is sane. | - the release architecture must have a working, tested installer I hope that's obvious why. :) | - the Security Team must be willing to provide long-term support for | the architecture If not, we can't release with that arch. I think this is also quite obvious. Of course, one way to get the security team to provide support might be to help them. | - the Debian System Administrators (DSA) must be willing to support | debian.org machine(s) of that architecture | - there must be a developer-accessible debian.org machine for the | architecture. Well, the second point is - I hope - obvious why we want this. This first one is just a conclusion of the second. | - the Release Team can veto the architecture's inclusion if they have | overwhelming concerns regarding the architecture's impact on the | release quality or the release cycle length This is just more or less an emergency-exit: If we consider an architecture really unfit for release, we can use our veto. This is one of the things I hope will never happen. Something else which is related to the number of architectures in testing is that we pay a price for every architecture: For example, the more architectures are included the longer the migration testing script takes. We are already at the limit currently (and also have out-of-memory issues from time to time). For example, currently we restrict the number of some hints to only 5 per day to keep up the scripts. Also, the udebs are not taken into account, which requires more manual intervention. With a lower number of release architecture, we can and will improve our scripts. Having said this, this all doesn't exclude the possibility for a non-release arch to have some "testing" which can be (mostly) in sync with the release architectures testing - just that if it breaks, the release team is not forced anymore to hold the strings together. For example, the amd64-people are doing something like that right now. We are all committed to the quality of debian, and for faster releases, and this proposal is one where we think we can help scale to more packages and architectures, and still get the release time to an acceptable level. I hope that this mail is able to shed some light onto these issues. Please accept my apologies for the missing information in the first mail. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
