> | - 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. > That should be easy to achieve on any of the currently supported debian architectures. Perhaps we need things like scratchbox or distcc to do this, but it can be done and there is sufficient interest in the community to make this happen. > | - 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. I strongly disagree with this. There is a need for a set of base packages to work, but it's entirely reasonable to have a release for eg m68k without KDE or other large package sets. It's not as if debian/m68k would be unusable without KDE packages for example. > > | - the release architecture must have a working, tested installer > I hope that's obvious why. :) > As long as FAI or even raw debootstrap counts, I can agree here. > | - 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 porting community is happy to help out here. Feel free to send requests for help, even to me. > | - 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 first one basically gives the DSA unlimited powers over which archs can be in debian. That's bad. > | - 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. > > If you don't expect it to happen, there is no reason for this being here. Ergo, please remove. > > 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. > > I fail to see why less archs allows you to improve the scripts. You can always improve them, regardless of how many usage they get. I believe there is sufficient algorithm knowhow in the debian developer community to solve the scalability problems. > > 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. > > The current proposal will lead to random arch specific forks. Each arch decides when they want a release and will include it's own fixes for arch specific problems. These fixes might go into debian or upstream or not (depends if debian or upstream wants them. Given the current hostile feelings of some debian people against anything no mainstream, I hope upstream will want them). If they are not integrated in debian or upstream, this will lead to multiple archs solving the same problems (consider endianess, alignment bugs, wrong use of bitfields,...). This will also lead to multiple inconsistent debian releases as the specific arch teams decide on when to release what version. This greatly diminishes the value of debian as a whole. > 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 fear this proposal will lead to lower quality (because of the unsynced releases), more work and less people willing to work on debian as a whole. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature