On Mon, Mar 21, 2005 at 08:08:57PM +0100, Wouter Verhelst wrote: > On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote: > > On Mon, Mar 14, 2005 at 10:48:10PM -0500, Branden Robinson wrote: > > > The next stage in the process is to actually sell the proposed changes for > > > etch to the developers at large[2]. There are several points which can and > > > should be discussed; I myself am not certain what the motivations for some > > > criteria are, and it would be good to have those documented so that we can > > > tell if an when they no longer apply. > > > Let me offer some examples: > > > * Why is the permitted number of buildds for an architecture restricted to > > > 2 or 3? > > - Architectures which need more than 2 buildds to keep up with package > > uploads on an ongoing basis are very slow indeed; while slower, > > low-powered chips are indeed useful in certain applications, they are > > a) unlikely to be able to usefully run much of the software we currently > > expect our ports to build, > Please leave it to our users to define what is useful. Does this mean "build it all and let the users decide for themselves what they want to use"? Or does it mean "ask the users before getting rid of packages that aren't used on the architectures"? If the former, that doesn't seem to leave much room for ever improving the return porters to embedded/slow systems will ever get on their buildd investment, does it? > > and b) definitely too slow in terms of > > single-package build times to avoid inevitably delaying high-priority > > package fixes for RC bugs. > I would not have any problem with multi-staged security announcements, > for example. Well, I guess just as I can't speak on behalf of all users and say they won't use KDE on m68k, you can't speak on behalf of them and say they're ok with having delayed security support for m68k. :) The security team seems historically unconvinced that staggered security announcements are worthwhile -- at least partly this is because staggered security announcements are more work, AIUI. In any case, you'd have to persuade them that this is a good idea before the release team could consider it. > > - If an architecture requires more than 3 buildds to be on-line to keep up > > with packages, we are accordingly spreading thin our trust network for > > binary packages. I'm sure I'll get flamed for even mentioning it, but > > one concrete example of this is that the m68k port, today, is partially > > dependent on build daemons maintained by individuals who have chosen not > > to go through Debian's New Maintainer process. > This is absolutely not the case. It is true that some of our buildd > machines have a local admin that are not developers or at least in NM; > but > * That is equally true for the buildd hosts of some of the other > architectures (e.g., s390, or sparc) > * Nobody has ever been offered to maintain a buildd host who was not at > least in NM. I did train Matthias Ulrichs and Goswin von Brederlow > when they were, but Goswin's machines were disconnected from w-b even > before he was rejected. I'm also quite sure today I won't do that > again, precisely because Goswin was rejected and I don't want to think > of what might've happened had he been able to upload trojanized > binaries (not that I think he would have done so). > I'm interested in what your base for the above assertion is. Merely a misunderstanding about the current state of affairs with the m68k port, it seems. Certainly with all the fuss Ingo has made over this issue in the past, I had the impression that it was actually a current issue -- not a hypothetical. > > Whether or not these > > particular individuals should be trusted, the truth is that when you have > > to have 10 buildds running to keep up with unstable, it's very difficult > > to get a big-picture view of the security of your binary uploads. > > Security is only as strong as the weakest link. > True; but these concerns can be better addressed by spelling out some > security requirements (and somehow ensuring they are being followed) > rather than imposing some random, unrelated, limit to the number of > hosts in use. FSVO "better"; having explicit security standards is good, but increasing the number of people (and machines) involved still increases the chances that somewhere, they will fail to be met. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature