On Wednesday 21 December 2005 12.28, Thijs Kinkhorst wrote: > On Wed, 2005-12-21 at 12:08 +0100, Adrian von Bidder wrote: > > On Tuesday 20 December 2005 19.33, Anthony Towns wrote: > > > ... it's worth considering a GR ... > > > > I really liked your analysis up to that point. > > > > I can't see any reason why we would need a GR here. > > I think it's an interesting approach. The issue at hand has been going > on for a long time, and it is needed that something is done. Keyword: something needs to be done. a GR is more talk. If there are people who are ready to do the work, the kind of GR being proposed here is absolutely not necessary, and if we don't have people ready to do the work, the GR won't change anything. aj: > -- > * The project expects the highest possible level of security > support for it users, and in particular that if we don't provide > better support than every other comparable distribution at all > times, we are beneath our own expectations. Producing a quality OS distribution has always been the goal of Debian, no GR needed. > * As such, security support for Debian 3.0 and 3.1 has been beneath > Debian's expectations. Given the amount of discussion we've already had, I guess a GR is not needed on this point. > * The existing security team is operating at capacity in providing > ongoing security support at present, and as a result, expecting > the security team to devote time and resources to resolving the > issue will cause Debian's security support to slip further beneath > expectations. Cool. Voting in a GR that some people are overworked/maxed-out. > * In order to avoid this, the project thus accepts that it is the > responsibility of the project at large to resolve this issue. The project at large already has this responsibility. How this responsibility is taken is what is at issue here. > * As such: > > - the project authorises a team consisting of Joey Hess, > Steve Langasek and Micah Anderson to review the stable security > team's processes and resources and recommend any changes > they believe appropriate. With the Project Leader's approval, > these recommendations shall be put into effect. I claim that most of the work can be done by interested developers 'just so', if they talk with the security team. If the security team is not responsive, the DPL is needed - he can change delegations. If delegations are needed to do the work, the DPL can do them. If the DPL won't do them, let's discuss that issue instead of this (IMHO silly) GR proposal. > - the project authorises the immediate addition of Martin Pitt > to the stable security team, with the expectation that he will > make every effort to ease the load on the existing members, > in so far as that is possible while ensuring his work does > not conflict or impede that of the existing members. Delegations are made by the DPL. > - the project authorises and expects all due assistance to be > provided to the review team and security team in carrying > out these activities, particularly by the Debian System > Administration team in ensuring access is available to > information on how the team is operating, and by the FTP Master > team in ensuring the capabilities of the security infrastructure > meet both existing and new expectations. Good coordination between the various infrastructure teams is absolutely necessary. If the existing teams won't work good enough, a probably won't change that. So we're back to either bitching about ftp-masters or debian-admin or DAM or about the DPL for not taking actions on these. (I guess debian-admin and DAM is the topic du jour, I've not seen much bad press about ftp-masters these days.) > * The project offers the security team its thanks and congratulations > for their efforts to date, and expects the activities noted above > to be undertaken with the respect and courtesy due the individuals > who have singlehandedly provided Debian with security support over > recent years. While I share this sentiment, no GR is needed for this either. So, short intermission: I'd like to thank the security team for all the work they've done over the past years, often in parallel to all the other work they've done for Debian in other areas. > -- back to Thijs: > What > especially needed is a decision on how it is going to be solved, The GR does not say how the problem should be solved. > and > after the decision has been made,that people work towards reaching that > goal. Since the GR already appoints people, I interpret it that - from your view - it's putting the cart before the horse. (This is slightly tongue in cheek. I realise that you probably don't see it that way.) Seriously: I'm back to my claim that *if* these people are interested to do the work, they don't need a GR and probably not even delegations to start working. > There's been a lot of talk, but it's needed that there's a clear > decision on the solution for the problem. A decision needs something of substance being proposed. This GR only proposes for some people to look at the situation - which can be done without GR, which this whole thread already proves: security and how it should be organised is already being discussed. > [ GR ...] It > can also be used for anything that you want a clear decision on, *clear* is the watchword. > after > some discussion. Trying to reach a real, clear consensus, especially in > cases like this, is very difficult. It's a fair instrument, because > everyone has an equal vote and it doesn't favour the loudest discussion > participant. Problem with a GR: it doesn't get any work done. Scenario I: * some people see something needs doing * 200+ thread on d-d * some (other) people are ready to do the work * the work is done. Scenario II: like the above, but there is a delay of several weeks while a GR confirms that the work needs doing. I don't see how II is good. And again: if the work in question is privileged, it's the task of the DPL to officially delegate people. And then there's the obvious Scenario III and IIIa: which is like I or II but no people actually do the work in the end. Where, again, I feel a GR doesn't make a difference. > So to me the obvious advantage would be that it brings clarity. To ask > you a question: why would you not hold a gr? What disadvantage does it > bring? Summary: this GR will just stir the pot and make discussion longer - I don't see that the end result will be different. cheers -- vbi -- featured link: http://fortytwo.ch/smtp
Attachment:
pgpX5V0d_ACyT.pgp
Description: PGP signature