* Thijs Kinkhorst (kink@squirrelmail.org) wrote: > Example minimal quality standards: > - it should have a large part of the packages built > - there should be enough buildds to keep up with security and new uploads > within reasonable time. > - there should be some minimal team to support this architecture > Any arch / porting team that satisfies our demands can be included. > > I honestly think that we (almost) all agree that putting these kind of > demands in place is not too much to ask. What exactly the thresholds > should be, that's a point of discussion. Let's first start to see whether > we agree that putting these demands on an arch this is neccessary to > remain our overall quality. we could then, if we do, start working on > drafting up the exact demands and parameters. These don't seem bad. It doesn't solve some of the problems I believe the proposal was intended to solve though: The release team doesn't think it can handle any more than X archs where X seems to be 4 or 5. I also understand it to be the case that the release team doesn't think additional people (or anything?) would help. Personally I can understand this in some regards, toolchain problems, d-i issues, etc that can't really be parallelized. I'm not convinced that this is the real driving factor with some of these requirements though and that this would be impossible to improve. As far as I can tell, without any actual word from them, I believe the ftpmasters/DSA feel that there's a certain number of machines (including things like buildds and whatnot) that they can support. In this case it doesn't seem like adding people could *not* help so I'm guessing the concern there is that there aren't enough trusted people willing to join ftpmasters/DSA to increase the number of machines capable of being maintained much. As I understand it, there wasn't anyone who's active on the security team who was at the meeting to help draw up the proposal but I believe it's been said that they also have an idea as to the max number of architectures they can support. It's not clear if that's got anything to do w/ the number of people or just the general quality of buildds and in some cases maintainers (kernel at least?). Personally I tend to think it's probably some of both- manpower and buildd infrastructure stability. There are some other technical issues having to do with the way wanna-build works and that having testing for all architectures will overload a very nice system with ssh connections. There is work being done to fix this already by using ssh connection cacheing. I'd hope for a more in-depth look and possible rewrite/rearchitecting of wanna-build, this limitation is somewhat concerning. Another technical issue is mirror space but I think that's handled just fine by only mirroring certain architectures, as I understand the plan is, and I think there will still be some mirrors who will mirror everything so I think that'll be alright in general. These are just my speculations and guesses, I'd love for those involved to step up and correct me. If I'm right it'd be nice to get some validation. Stephen
Attachment:
signature.asc
Description: Digital signature