Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Mar 16, 2007 at 12:15:08PM +0100, Josip Rodin wrote: On Fri, Mar 16, 2007 at 12:53:52AM +, Steve McIntyre wrote: IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. The idea behind the RT setup is to help us on the way to growing the teams. It might sound unlikely to some, but I'm told there have been problems in the past with people tripping over each other when trying to work on tasks. We have multiple volunteers who want to help out; as more people come on board who may not have worked together in the past, the probability of coliisions grows substantially. That's one place where RT will help. It will also allow people to keep better track of what jobs have been requested and help in terms of feedback to the requestors too. It's not a magic bullet (we all know that), but it should help. IMO the best effect of a request tracker will be that it will help document the typical workings of the team, and that way help any new members get acquainted with what needs doing and how it gets done. Poor man's documentation, if you will, but actual documentation nevertheless. Yeah, good point. That's a very useful side-effect. The collision handling by 'taking' tasks in the request tracker prior to doing them is a nice idea, but, it's neither a particularly convenient solution (people tend to hate administrivia), and fortunately the problem is not such a show-stopper (the task still gets done, even if a few more man-time-units are wasted). OK. I think it might also be a useful way for new people to be evaluated - assign some of the easier / less critical tasks to them and see how they work on them. It'll help track those after the fact. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane... signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Mar 16, 2007 at 12:53:52AM +, Steve McIntyre wrote: IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. The idea behind the RT setup is to help us on the way to growing the teams. It might sound unlikely to some, but I'm told there have been problems in the past with people tripping over each other when trying to work on tasks. We have multiple volunteers who want to help out; as more people come on board who may not have worked together in the past, the probability of coliisions grows substantially. That's one place where RT will help. It will also allow people to keep better track of what jobs have been requested and help in terms of feedback to the requestors too. It's not a magic bullet (we all know that), but it should help. IMO the best effect of a request tracker will be that it will help document the typical workings of the team, and that way help any new members get acquainted with what needs doing and how it gets done. Poor man's documentation, if you will, but actual documentation nevertheless. The collision handling by 'taking' tasks in the request tracker prior to doing them is a nice idea, but, it's neither a particularly convenient solution (people tend to hate administrivia), and fortunately the problem is not such a show-stopper (the task still gets done, even if a few more man-time-units are wasted). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, Mar 13, 2007 at 01:09:12AM +0100, Frans Pop wrote: On Friday 23 February 2007 03:13, Anthony Towns wrote: I'm trying to be descriptive here rather than prescriptive or proscriptive [...] I appreciate the clear overview of the current status. I would also like to say that I feel the people currently holding positions in the various teams are all highly competent, have the best interests of Debian at hart and do the work that is done well. However, the last few years I have also had a very strong conviction that the teams are just too small, that too much - often minor and routine - work is not getting done, or at least not getting done within a reasonable time frame. And also that even within the teams certain tasks too often depend on the availability of a single person instead of the members fluidly taking over jobs that need doing from eachother. It is also a fact that the persons who are in these teams have for the most part been part of them for a relatively long time already. They are not the same persons they were when they started the job. Some now have a lot less time available (or even to some extend conflicting priorities) due to new jobs, others have gotten less motivated to work on Debian due to changes in the project. Yup, agreed in these 3 paragraphs. IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. The idea behind the RT setup is to help us on the way to growing the teams. It might sound unlikely to some, but I'm told there have been problems in the past with people tripping over each other when trying to work on tasks. We have multiple volunteers who want to help out; as more people come on board who may not have worked together in the past, the probability of coliisions grows substantially. That's one place where RT will help. It will also allow people to keep better track of what jobs have been requested and help in terms of feedback to the requestors too. It's not a magic bullet (we all know that), but it should help. Of course I understand that in these particular teams the project (and the current members) want to make very sure that new members have the right mentality as mistakes on any of the core project machines can have huge consequences. Fine, but you cannot convince me that among the 100-150 more active developers there are not sufficient people that have shown through their contributions, their attitude in discussions and so on that they _are_ basically competent and trustworthy. We have quite a number of volunteers already. We have a list of people to get back to in order to try and organise things with them, and I must admit that things are overdue on that front. It's time to get it moving. This can be further guarded by having a trial period with mentoring by existing members, by not giving out full authorizations immediately, and by having very clear agreements about what jobs a new member can do by himself, what needs to be reviewed by existing members, and what he should absolutely not touch. Yup, sounds eminently sensible. So, basically my question remains: why does it have to be so incredibly difficult to allow new members into these teams? Historical reasons as much as anything else. That's not an excuse, and things should be improving soon. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] We don't need no education. We don't need no thought control. signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, 13 Mar 2007, Frans Pop wrote: [quoting http://lists.debian.org/debian-project/2007/03/msg00062.html ] ... IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. Amen. I seldomly read such precise and explicite words that describe the main problem in Debian. Each paragraph was well written and I just cuttet the quote short. If there would be a DPL candidate that would explicitely express the intend to make it his main task to change this situation I would rank him top most and everybody who ignores this problem will be ranked below None of above. Kind regards Andreas. PS: No need for continuing cross posting debian-project and debian-vote but I wanted to make people aware of this very interesting posting on project. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, Mar 13, 2007 at 01:09:12AM +0100, Frans Pop wrote: So, basically my question remains: why does it have to be so incredibly difficult to allow new members into these teams? Probably because fixing them requires spending a sufficient number of man-hours and a substantial amount of will power, enough so that properly fixing them always gets ranked in the we can do it later category. But anyway, it doesn't really matter, I shouldn't rant here, there's no point. There should simply be no more question marks; that sentence should be rephrased into It does not have to be so incredibily difficult to allow I have no problem with development work being funded, but an organization that is founded on volunteers should be able to maintain its core infrastructure using those volunteers. About this point... I'd mention that we could ponder reimbursing people for doing something either particularly intensive or particularly menial. But anything like that should only happen once we get past the whole unclogging phase. (Although I would actually ponder reimbursing an existing debian-admin for their time going through three dozen machines running visudo, that is just tedious :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Friday 23 February 2007 03:13, Anthony Towns wrote: I'm trying to be descriptive here rather than prescriptive or proscriptive [...] I appreciate the clear overview of the current status. I would also like to say that I feel the people currently holding positions in the various teams are all highly competent, have the best interests of Debian at hart and do the work that is done well. However, the last few years I have also had a very strong conviction that the teams are just too small, that too much - often minor and routine - work is not getting done, or at least not getting done within a reasonable time frame. And also that even within the teams certain tasks too often depend on the availability of a single person instead of the members fluidly taking over jobs that need doing from eachother. It is also a fact that the persons who are in these teams have for the most part been part of them for a relatively long time already. They are not the same persons they were when they started the job. Some now have a lot less time available (or even to some extend conflicting priorities) due to new jobs, others have gotten less motivated to work on Debian due to changes in the project. IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. The way to get new members in a team is not to say prove yourself first by working on something that needs doing (but don't count on us for any information or support) and we'll consider you in about 5 years time. That just does not motivate people. Of course I understand that in these particular teams the project (and the current members) want to make very sure that new members have the right mentality as mistakes on any of the core project machines can have huge consequences. Fine, but you cannot convince me that among the 100-150 more active developers there are not sufficient people that have shown through their contributions, their attitude in discussions and so on that they _are_ basically competent and trustworthy. This can be further guarded by having a trial period with mentoring by existing members, by not giving out full authorizations immediately, and by having very clear agreements about what jobs a new member can do by himself, what needs to be reviewed by existing members, and what he should absolutely not touch. A few examples of issues not mentioned in your mail that I have experienced first hand: - no response at all during the last 3 months or so to requests to authorize new people for debian-doc or debian-www; only after /msg'ing a friendly DSA member personally were two accounts added, there are most likely other requests still pending - Joerg does a great job processing NEW (both quality and quantity), but the backlog grows fast if he's not/less available for a while - same for BYHAND processing (doc-debian is now waiting for a month); often requires repeated and active pinging - recently we had a disk full problem for wiki.d.o which required emergency action; is there no regular monitoring for this? (I understand that a move to a different machine was already planned, but still, diskspace problems don't need to happen) - the time to bring back services after a failure or issue is sometimes very long; partly for logistical reasons, but also due to lack of manpower or priority; progress or reasons _why_ it takes longer for some machines to be revived are not communicated to the community So, basically my question remains: why does it have to be so incredibly difficult to allow new members into these teams? Ah, before I forget. As to having paid members of these teams... Why? IMO there are plenty of capable, trustworthy and motivated people to be found among our volunteers. Also, I very much dislike the idea of Debian being dependent on a budget based on outside funding for execution of it's core and routine tasks. What happens if the IT industry hits another slump and the funding is discontinued? I have no problem with development work being funded, but an organization that is founded on volunteers should be able to maintain its core infrastructure using those volunteers. I also have huge problems with agreed upon infrastructural changes not being implemented until funding becomes available, unless there _first_ is an open call from help from other members of the volunteer community. Cheers, FJP pgp6mWkilnV6f.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, Mar 13, 2007 at 01:09:12AM +0100, Frans Pop wrote: So, basically my question remains: why does it have to be so incredibly difficult to allow new members into these teams? As opposed to joining the d-i team for example ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Em Sex, 2007-02-23 às 11:41 +0100, Marc Haber escreveu: I feel that RT is not a silver bullet, and adresses a non-issue in my opinion. I fear that its introduction will not help in solving the pressing issue that makes people stop caring about things. While I agree that RT is no silver bullet, having a history and a list of open issues would be a good thing, as long as we are able to browse it. Our own BTS teaches us the importance of having a publicly viewable 'open issues' tracker, which serves as TODO, quality measurement, and even documentation. I am one of the somewhat demotivated by the apparent lack of 'throughput' of some of Debian's base, and am affected by it as well (I have requested a GPG key replacement (the new key is 4096, against 1024 of the current) and had no answer for months now). I do believe that more transparency would be very useful. Remains to be seen if the RT install will actually be transparent enough. See you, -- Gustavo Noronha [EMAIL PROTECTED] http://kov.eti.br/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/27/07, Francesco P. Lovergine [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: Exactly Martin, if the plain is a publicly accessible interface to track requests for DSA, we've our BTS! The security argument sells the idea that a RT (not publicly accessible) would be better. That's why #408150 wasn't solved as i have requested. I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Two different tracking systems for only one project is a bad idea, if somebody show a real use-case then what we need is a developers only accessible BTS, not RT. I still fail to see a need for a second BTS setup though. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 10944 March 1977, Gustavo Franco wrote: I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Get a new machine sponsored somewhere. The sponsor will send you the initial root login which usually includes a password. You dont want anyone to see that. -- bye Joerg NM-fun: The Debian project, at least for me, is not a joke, [...] pgp3lhiIKN6qT.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 10944 March 1977, Gustavo Franco wrote: I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Get a new machine sponsored somewhere. The sponsor will send you the initial root login which usually includes a password. You dont want anyone to see that. -- bye Joerg NM-fun: The Debian project, at least for me, is not a joke, [...] pgpMXKAW80DAy.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/28/07, Joerg Jaspert [EMAIL PROTECTED] wrote: On 10944 March 1977, Gustavo Franco wrote: I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Get a new machine sponsored somewhere. The sponsor will send you the initial root login which usually includes a password. You dont want anyone to see that. Hi Joerg, This use-case was already covered above without RT and BTS usage. Do you really want that initial root login password flying in plaintext until it reaches a private RT? What's the point of a private RT then? mitm attack here is trivial, to say the least. As i said, nobody should send it to BTS, RT or email directly in plaintext, these sensible information might be sent by mail, out of the tracker and encrypted. The tracker is still valid here because the issue title would be something like sponsored machine setup and its status should be available for anyone (not the server password itself, come on), or at least any Debian developer, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: Exactly Martin, if the plain is a publicly accessible interface to track requests for DSA, we've our BTS! The security argument sells the idea that a RT (not publicly accessible) would be better. That's why #408150 wasn't solved as i have requested. I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Sat, Feb 24, 2007 at 11:41:11PM -0800, Steve Langasek wrote: On Sat, Feb 24, 2007 at 04:09:46PM +0100, Pierre Habouzit wrote: I'm not sure what you're asking to be communicated. The following of the mail looks perfect to me, I would really have liked to have a place where I could have read that in the first place. db.d.o/machines.cgi does not lists that. But, the only part of this that was actually information was the first paragraph, which only moderately elaborates on what's already present on db.debian.org, and doesn't really change the prognosis for the near future, i.e., porting machine down, no ETA. Well, that is information, I don't necessarily want an ETA RSN, I just want to know if there is one yet, and if not, to be sure I'll know when there will be one. That's exactly what people are expecting: be sure than when _there will be_ some ETA, or more informations, those will come as soon as available. You know, communication thing ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpupXtQwDWKl.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Sat, Feb 24, 2007 at 04:50:50PM -0800, Don Armstrong wrote: On Sat, 24 Feb 2007, Mark Brown wrote: You are assuming that the person sending the e-mail is aware that the information they are sending is going to end up publically visible. So indicate that it'll be publicly archived, and that private information should be encrypted and sent out of band in the footers of the messages sent out. That's got rather a lot of obvious failure modes... In any event, even that isn't really a reason to not allow Debian Developers to have access to the request tracker, although it may be a reason to restrict the general public. Right, that's one approach that might work well enough for people. My point is that we shouldn't swing so far to openness that we end up causing people nasty surprises or with something that needs to be circumvented too often in normal operation. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Ok, here's an example with enough tools to handle most of the common cases. For now you can get these tools from svn://svn.kitenet.net/joey/trunk/src/packages/unreleased/jetring/ [EMAIL PROTECTED]:~ls jetring changeset-accept* changeset-review* keyring-gen* changeset-apply* keyring-explode* [EMAIL PROTECTED]:~export PATH=$PATH:~/jetring [EMAIL PROTECTED]:~cd ~/tmp/debian-keyring-2005.05.28/keyrings [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringskeyring-explode emeritus-keyring.pgp emeritus-keyring emeritus-keyring/add-17D57681 emeritus-keyring/add-6F7267F5 emeritus-keyring/add-B269698D emeritus-keyring/add-647B8331 emeritus-keyring/add-64433805 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead emeritus-keyring/add-001B3BA1 Comment: extracted from emeritus-keyring.pgp by keyring-explode Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (GNU/Linux) mQBtAzI+bhkAAAEDAOn0rvREGipkloa17NRJcSHweJJuhGo5EIPM3XDXbfXF4j18 TBWgGisic/QqtGvOwVVgQitS1evqOHgcRrNOPc/0tOuruR8qtEX33ypwjiZlK30M evm8E9wUEkkpABs7oQAFEbQnQmpvcm4gQnJlbmFuZGVyIDxiam9ybkBicmVuYW5k ZXIucHAuc2U+iQB1AwUQM9T0FhQSSSkAGzuhAQEJTQL9FF2qV4aBYgWKdKu4MdG6 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead emeritus-keyring/index 9c55ce36c00df3d6edec08106db06be1 add-17D57681 9316b0b1f37b97d99336df760deac6ef add-6F7267F5 e2480c78d9b39694775f6bec21023e9b add-B269698D f868db4c2eff8751e8fdc53d6b105c0b add-647B8331 c68795f636ecf52fa6cdff7e71b18915 add-64433805 0836a942d9aa1ca54c9976969a26380c add-DEA67011 5f1af519711e704104550ce984d6033c add-B1CE8961 7c646b8bb334684d164147221c407424 add-5BB0DA6D 4627e1f9cc0c91cfbb5e2c5a3adb45b9 add-FA00F50D 6e64f607284940c6842932f1bf55b4bc add-ABB90E15 keyring-explode is a one-time operation, so a bit slow, but now the changesets are ready for use. First, let's rebuild the keyring from them, and compare to make sure no data is being lost (or added!): [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringskeyring-gen newring.gpg emeritus-keyring Applying emeritus-keyring/add-17D57681 ... gpg --import gpg: key 17D57681: public key Joel Klecker [EMAIL PROTECTED] imported gpg: key 17D57681: Joel Klecker [EMAIL PROTECTED] not changed gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: unchanged: 1 gpg operation complete ... Applying emeritus-keyring/add-F9033421 ... gpg --import gpg: key F9033421: public key Herbert Xu [EMAIL PROTECTED] imported gpg: key F9033421: Herbert Xu [EMAIL PROTECTED] 2 new signatures gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: new signatures: 2 gpg operation complete All changesets applied ok. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsls -l newring.gpg emeritus-keyring.gpg -rw-r--r-- 1 joey joey 167537 Feb 24 02:03 emeritus-keyring.gpg -rw-r--r-- 1 joey joey 94855 Feb 24 02:06 newring.gpg [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsgpg --no-default-keyring --keyring ./emeritus-keyring.gpg --list-keys a [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsgpg --no-default-keyring --keyring ./newring.pgp --list-keys b [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsdiff -u a b --- a 2007-02-24 02:15:29.0 -0500 +++ b 2007-02-24 02:15:35.0 -0500 @@ -1,5 +1,5 @@ -./emeritus-keyring.pgp --- +./newring.gpg +- pub 1024R/17D57681 1996-06-26 uid Joel Klecker [EMAIL PROTECTED] uid Joel Klecker [EMAIL PROTECTED] @@ -161,10 +161,10 @@ pub 1024R/22714B25 1998-08-30 uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] -uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] +uid Stephen Crowley [EMAIL PROTECTED] pub768R/21978C61 1996-08-13 uid Hubert Weikert [EMAIL PROTECTED] @@ -347,7 +347,6 @@ pub 1024R/8F23DC91 1994-12-20 uid Joe Reinhardt [EMAIL PROTECTED] uid Joe Reinhardt [EMAIL PROTECTED] -uid Joe Reinhardt [EMAIL PROTECTED] uid [EMAIL PROTECTED] uid [EMAIL PROTECTED] uid Joseph M. Reinhardt [EMAIL PROTECTED] Ok, no significant changes, only id rearrangement and dup removal. I've done the same for debian-keyring.gpg, with similar results, just took a bit longer. On to making changes.. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringscat joeyh.retired Changed-By: Joey Hess [EMAIL PROTECTED] Comment: had to happen some day Date: Sat, 24 Feb 2007 02:18:51 -0500 Action: delete-key 788A3F4C Data: y [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-review newring.gpg joeyh.retired y gpg
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
* Anthony Towns: I'm trying to be descriptive here rather than prescriptive or proscriptive Does this mean that this message is not meant to create any new delegations? Below you say otherwise, so I'm confused. * Debian System Administration (DSA) - delegated authority to determine unofficial Debian services via delegation of debian.net subdomains Hasn't debian.net DNS management delegated to others? In my opinion the only roles that have any DPL delegation part are the ones I've described as delegated authority above -- ie, DAM's ability to determine who's a Debian developer, and DSA's management of the debian.org and debian.net domains. Among other things, ftp-master decides what's acceptable for the archive (see the Java 5 addition if this is not clear), and IMHO, this activity needs delegation, too. But according to my reading of the Constitution (Article 2.1(2)), you cannot delegate to a team you are a member of, anyway. I'm positively surprised that DSA and keyring-maint themselves want to use RT to improve their communication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote: Sure, I just wanted to show it can be used for anything you'd do via --edit-keys. I'm not sure what classes of changes keyring-maint typically makes so it seemed best to cover all of them. There's a fairly detailed changelog in the debian-keyring package. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 08:05:33PM +0100, Josselin Mouette wrote: Anthony Towns wrote: I've been delaying this mail for a while now Is it purely coincidental that it was sent the same day as your nomination for the DPL elections? No, it's all part of his super secret campaign strategy to turn -project into an orgy of retarded conspiracy theories in order to win votes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
* Anthony Towns: If they don't do it, and it's important, someone else will. We aren't prepared to deal with that in some important cases. For instance, if large numbers of identically-versioned binary packages are published, there will quite a few issues in the short term (and fear of such confusion already led to drastic measures on behalf of the project). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 10940 March 1977, Florian Weimer wrote: - delegated authority to determine unofficial Debian services via delegation of debian.net subdomains Hasn't debian.net DNS management delegated to others? Yes and no. DSA is responsible for keeping it running, and they can freely add sub-domains or stuff to it. They just also provide an interface for DDs to add host entries on their own. -- bye Joerg SUSE = Soll Unix Sein, Eigentlich. pgp46S2GxTjHJ.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Florian Weimer [EMAIL PROTECTED] wrote: * Anthony Towns: If they don't do it, and it's important, someone else will. We aren't prepared to deal with that in some important cases. For instance, if large numbers of identically-versioned binary packages are published, there will quite a few issues in the short term . Hm, what problems are you talking about? If I upload $ ls src/Packages/texlive-new/*2007-1~2_*.deb | wc -l 80 $ (from 5 source packages) will that trigger those problems? (and fear of such confusion already led to drastic measures on behalf of the project) What measures? Can you provide any links? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
* Frank Küster: We aren't prepared to deal with that in some important cases. For instance, if large numbers of identically-versioned binary packages are published, there will quite a few issues in the short term . Hm, what problems are you talking about? Right now, if there's a bug report in the BTS that, for example, cook 2.26-1 has been miscompiled on amd64 and has got an important bug as a result, we can be pretty sure that the submitter talks about the version in our archive. If there was a separate buildd network that did not upload to the official archive and was somewhat popular among our users[1], it's no longer obvious which version is broken. (And for interoperability with various bug tracking efforts, you'd really want to keep the official version numbers.) [1] It could be more up-to-date, use more conservative GCC defaults (-fwrapv -fno-strict-aliasing -fstack-protector), or provide an audit trail that gives people a warm fuzzy feeling. (and fear of such confusion already led to drastic measures on behalf of the project) What measures? Can you provide any links? http://lists.debian.org/debian-devel/2007/01/msg00760.html
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 01:59:07AM -0500, Joey Hess wrote:
How would you convert gpg --refresh-keys into changeset based
operations, I wonder? Maybe you could do it by something like: [...]
That's beautiful, if we can figure out what changed-keys is. :-)
Two ways: either parse the output of gpg as it's running:
gpg: requesting key CA57AD7C from ldap server keyserver.pgp.com
gpg: key CA57AD7C: PGP Global Directory Verification Key not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: requesting key DDD11D8A from hkp server subkeys.pgp.net
gpg: key DDD11D8A: Ted Percival (midg3t) [EMAIL PROTECTED] 74 new
signatures
gpg: Total number processed: 1
gpg: new signatures: 74
or run gpg --list-keys --verbose on the old and new keyring, and see
what differences you find.
I guess we need something that'll do that anyway, though. How about the attached
as a proof of concept?
] $ ./diffring.pl ./debian-keyring.list ./debian-keyring-aj.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -181)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -86)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -191)
] Removed uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
or
] $ ./diffring.pl ./debian-keyring-aj.list ./debian-keyring.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +181, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +86, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +191, -0)
] Added uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
It works on the output of `gpg --verbose --list-sigs', which is a bit
slow on a full keyring. Oh well.
On Sat, Feb 24, 2007 at 03:04:57AM -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~ls jetring
May Manoj's typos live forever :)
[EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead
emeritus-keyring/add-001B3BA1
Comment: extracted from emeritus-keyring.pgp by keyring-explode
Action: import
Data:
-BEGIN PGP PUBLIC KEY BLOCK-
No import date?
Ok, no significant changes, only id rearrangement and dup removal.
diffring.pl should deal with those fwiw. Doesn't deal with revocations, and
may not deal well with subkeys.
Cheers,
aj
#!/usr/bin/perl -w
# Copyright (c) 2007 Anthony Towns
# GNU GPL; v2 or later
# Gives an overview of what changed between two keyrings
use strict;
my $l = parse_keyring($ARGV[0]);
my $r = parse_keyring($ARGV[1]);
foreach my $ku (sort keys %{$l}) {
if (not defined $r-{$ku}) {
my $n = @{$l-{$ku}};
print Removed uid $ku (sigs: $n)\n;
} else {
my $a = $l-{$ku};
my $b = $r-{$ku};
my ($i, $j) = (0,0);
my ($del, $add) = (0,0);
while() {
my $A = $a-[$i] || G;
my $B = $b-[$j] || G;
# avoid dupes:
if ($i 0 $A ne G $A eq $a-[$i-1]) { $i++; next; }
if ($j 0 $B ne G $B eq $b-[$j-1]) { $j++; next; }
# compare:
my $x = $A cmp $B;
if ($A eq G and $B eq G) { last; }
if ($x == 0) { $i++; $j++; next; }
if ($x 0) { $add++; $j++; next; }
if ($x 0) { $del++; $i++; next; }
}
if ($add or $del) {
print Updated uid $ku (sigs: +$add, -$del)\n;
}
}
}
foreach my $ku (sort keys %{$r}) {
if (not defined $l-{$ku}) {
my $n = @{$r-{$ku}};
print Added uid $ku (sigs: $n)\n;
}
}
sub parse_keyring {
my $k = shift;
my $fd;
#open $fd, gpg --no-default-keyring --no-auto-check-trustdb --keyring $k --verbose --list-sigs | or die couldn't open keyring $k: $!;
open $fd, $k or die couldn't open gpg--list-sigs-output $k: $!;
my $x = build_key_hash($fd);
close($fd);
return $x;
}
sub build_key_hash {
my $f = shift;
my $keys = {};
my ($k, $u);
while ($f) {
chomp;
if (m/^\s*$/) {
# skip
} elsif (m/^pub/) {
$k = substr($_,6);
$k =~ s/\s.*//;
$u = undef;
} elsif (defined $k m/^sub/) {
$u = substr($_,6);
$u =~ s/\s.*//;
$keys-{$k-$u} = [];
} elsif (defined $k m/^uid/) {
$u = substr($_,21);
$keys-{$k-$u} = [];
} elsif (defined $k m/^rev/) {
# skip
} elsif (defined $k defined $u m/^sig/) {
push @{$keys-{$k-$u}}, substr($_, 13, 19);
} else {
#print XXX: $_\n;
}
}
foreach my $ku (keys %{$keys}) {
$keys-{$ku} = [ sort( @{$keys-{$ku}} ) ];
}
return $keys;
}
signature.asc
Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: I think they contribute /better/ if they aren't closely supervised. I think that's seen some results over the past year, including much improved spam protection for debian.org addresses, Er, we now have implemented measures that are actually years old. That's certainly a result, but it's not really a *good* result, because a lot of time was wasted. a new and much faster ftp-master along with two dinstall/britney runs a day I'm not acquainted with the specifics, but if the hardware upgrade brought on a much faster service, then that's also a result that is certainly a result, but not a *good* result, because it could have been achieved years ago. So, to go back to something that you started with... I think it's worth recognising that when we say we're not doing a good enough job, *we* are still the ones setting and raising the bar. ...there was no bar-raising being done there, only lowering. :| And I would argue that this happens *because* there is little real accountability and/or supervision. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Sat, Feb 24, 2007 at 05:14:17AM -0800, Steve Langasek wrote: On Fri, Feb 23, 2007 at 10:44:55AM +0100, Pierre Habouzit wrote: Do you want a Simple example ? For almost 4 or 5 months (if not more) there is no Alpha machine available to developers, one being restricted, the other in lock down, waiting for a setup I guess (-- did you remark the I guess ? I mean I don't know what's going on, and nobody knows afaict). The problem is, I'm now helping packaging the glibc, and we have a couple of alpha-only bugs. Things really stupid like headers problems, that would almost take a full minute to be fixed. BUt that bug fix is pending james, Ryan or a local admin work (again I've to guess), and nothing is coming, neither explanation on why no alpha machine is accessible, nor why it takes so long, nor an ETA. [...] I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. I'm not sure what you're asking to be communicated. The following of the mail looks perfect to me, I would really have liked to have a place where I could have read that in the first place. db.d.o/machines.cgi does not lists that. https://db.debian.org/machines.cgi correctly documents the status of escher as 'lock down', and yes, this status is unchanged for many months because of the lack of a kernel image for alpha that includes the fix for the last security hole. It's been suggested that the local admin might find the time to work on this subsequent to the relocation (the same relocation that caused the alpha buildd outage -- goedel and escher are hosted together). But it would be premature to plan around that, currently escher is not just locked down, it doesn't respond to pings at all. I plan to see what I can do to help on this if it remains unresolved, but not until post-etch... thanks for this information. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpUhwY28bGfs.pgp Description: PGP signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On 2/24/07, Joey Hess [EMAIL PROTECTED] wrote: Anthony Towns wrote: That's a technical issue, however -- one that seems like it should be emminently solvable. Ensuring that any such solution is written in a way that encourages auditability (of the code, of the input and of the output) is an important part though, and I don't know that anyone even has a good understanding of how that would be achieved. That probably means someone needs to try to implement it, and then we can see what doesn't work. Perhaps something like this: [ Very elaborate scheme snipped ] I would have though that the keyring maintenance needs much simpler tools. Is there really a need for editing individual keys? Looking at the quote ] (c) right now changes to the keyring are fundamentally unauditable ] unless they're done by a single person on a trusted machine with ] trusted scripts. There are a bunch of ways to solve this, but ] the best suggestion I've heard so far is something that breaks ] down the 17Mb binary blob of 'debian-keyring.gpg' into single key ] auditable chunks that can then be managed in a sane way. The ] scripts to do these would have to be simple first and foremost so ] they could be audited. it seems to me that a very simple solution would need 1. A trusted machine with a subversion (say) repository, to which only the keyring-assistants have access. 2. A directory in this repository with one *.key file for each key in the keyring. The *.key files should of course be in ACSII-armored format. 3. A three-liner script that creates the keyring by importing all the *.key file into an empty keyring, as AJT suggested. So when a keyring-assistant processes a keyring request, like My old key 0xDEADBEEF is obsolete, here is my new one 0x12345678, the assistant removes DEADBEEF.key and adds 12345678.key to the repository with a commmit messages including the email with the request. When the keyring maintainer has time, she verifies the commits, runs the script, and uploads the new keyring. The commits can be sent to a mailing list (or whatever) and other can see that things are moving along, and verify the keys if they are so inclined. Or... is my understanding of what kinds of requests the keyring maintainer gets wrong? Cheers, Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On 2/25/07, Joey Hess [EMAIL PROTECTED] wrote: Jens Peter Secher wrote: it seems to me that a very simple solution would need 1. A trusted machine with a subversion (say) repository, to which only the keyring-assistants have access. 2. A directory in this repository with one *.key file for each key in the keyring. The *.key files should of course be in ACSII-armored format. 3. A three-liner script that creates the keyring by importing all the *.key file into an empty keyring, as AJT suggested. Since that could be set up in 15 minutes, and this has been an unresolved for a year or two, I assume it doesn't meet keyring-maint's needs, and so I prefer to develop something that meets all needs I can envision. So, I am obviously missing some requirements here. I will very gladly help out if there is anything else that needs to be coded up. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Sat, 24 Feb 2007, Mark Brown wrote: You are assuming that the person sending the e-mail is aware that the information they are sending is going to end up publically visible. So indicate that it'll be publicly archived, and that private information should be encrypted and sent out of band in the footers of the messages sent out. In any event, even that isn't really a reason to not allow Debian Developers to have access to the request tracker, although it may be a reason to restrict the general public. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote: I guess we need something that'll do that anyway, though. How about the attached as a proof of concept? Nice output, but a bit buggy in my tests. I've changed it to use --with-colons, and keep the --with-colons output, so it looks like a diff. (I also added caching for speed.) [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsdiffring foo3.gpg foo4.gpg -pub:-:1024:17:826FCAC21E880A84:1047319183:::-:::scESC: -uid:-1047319184::2993CFDACF30643F1A22EBD25A0E28086FD157B2::Frans Pop (Debian) [EMAIL PROTECTED]: -uid:-1116808856::16874BA594735C2647F63A853EFBAA373FD2E0FE::Frans Pop [EMAIL PROTECTED]: pub:-:1024:17:DADA79CD788A3F4C:-:::-:::scESC uid:--::558865A42A128E974449AF46596C86154E3F63B4::Joey Hess [EMAIL PROTECTED] uid:--::0D93ACA144ADD501DD5A3372FA0FCFD1E5DE3B29::Joey Hess [EMAIL PROTECTED] -uid:--::ECD310B7100369A24C3AA0FC4CC2A9D5DC74629B::Joey Hess [EMAIL PROTECTED] uid:--::4A5F289163A83EABBEA512B09FC99AE21947EE06::Joey Hess [EMAIL PROTECTED] sub:-:2048:16:3880BC071950ED18:-::e A switch could be added to futher process and prettify that, but as it is, it's useful for input to other tools, and it allows display of even the most obscure changes. Rather than a specialised tool to refresh keys from a keyserver, I wrote a more general tool that uses diffring to generate changesets between two keyrings. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-gen foo3.gpg foo4.gpg merging my random changes delete-D523A6E660062884 modify-DADA79CD788A3F4C [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-accept debian-keyring delete-D523A6E660062884 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-accept debian-keyring modify-DADA79CD788A3F4C -- see shy jo signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/24/07, Mark Brown [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 12:16:52PM -0300, Gustavo Franco wrote: That's up to the person behind the *my* you wrote, disclose $ADDRESS and $NUMBER. The same can't be said about our email address, so what's the point really? I don't think the DSA members will want to disclose this kind of information and if somebody does, they won't be forced to do so. Let me rewrite what would happen IRL, IMHO: Please send the machine to my home address - I'll drive out to the DC and put the machine on-line ASAP. Give the sipping company my phone number. I'll send you *my personal details* privately. You are assuming that the person sending the e-mail is aware that the information they are sending is going to end up publically visible. With a lot of tracking systems this may not be the case. In the particular case of RT the work flow appears to involve generating e-mails to which anyone can reply, with replies causing information to be added to the ticket. This means that it's easy for someone to put information in there without ever realising that there's a public archive. Well, based on what you wrote we don't need a new tracking system but just a new feature into BTS. If a user send a report (or reply) to the pseudo-package $FOO, it will return a message to him warning that if replying to that auto-generated message will forward his message into a public archive. That's up to him avoid reply the message and rewrite it, if needed. It won't cover the case where the private information goes through non trusted pipes. It can't be easily solved with BTS nor RT though. I still disagree with a private tracking system for DSA. Almost all the information isn't sensible and can be there, the details can be passed privately and it's up to the message submitter and nobody else. It isn't like a person out of DSA can disclose sensible information that will put DSA stuff at risk. I do agree that we should make an effort to make information available but we need to be aware of the problems that could arise and take steps to mitigate them. The case with keyring-maint is even worse for this since people might decide to do things like send scans of ID documents. I agree, but the answer isn't a private (DSA or visible by DDs only) tracking system even if it's RT or a new debbugs setup, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Sat, Feb 24, 2007 at 04:09:46PM +0100, Pierre Habouzit wrote: I'm not sure what you're asking to be communicated. The following of the mail looks perfect to me, I would really have liked to have a place where I could have read that in the first place. db.d.o/machines.cgi does not lists that. But, the only part of this that was actually information was the first paragraph, which only moderately elaborates on what's already present on db.debian.org, and doesn't really change the prognosis for the near future, i.e., porting machine down, no ETA. The rest is either rumor, or useless statements of intent on my part... :) https://db.debian.org/machines.cgi correctly documents the status of escher as 'lock down', and yes, this status is unchanged for many months because of the lack of a kernel image for alpha that includes the fix for the last security hole. It's been suggested that the local admin might find the time to work on this subsequent to the relocation (the same relocation that caused the alpha buildd outage -- goedel and escher are hosted together). But it would be premature to plan around that, currently escher is not just locked down, it doesn't respond to pings at all. I plan to see what I can do to help on this if it remains unresolved, but not until post-etch... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: On a personal note, in my experience the most effective way of working with James and Ryan is to trust that they generally know what they're doing and more or less leave them to get on with making things better on their own rather than hassling them for status reports or similar. Well, that leave one obvious question then, are they the best people for the job ? because I'd really prefer people that work 10% less, to communicate what they do in the other 90% of their task, so that everyone knows what's going on, and can plan their own job decently. My point is, many tasks in debian depend on what DSA/DAM/... do and especially when. Event if (for the sake of the argument) I admit that things get eventually done, the unknown time part _is_ generating a _lot_ of frustration. Just leave them to their own devices isn't something you'll see recommended in management books, but when people are doing stuff that they care about for fun, it's worth considering. This is just handwaving: letting them in their dark corner because they work faster like that, is not related to the issue that is debated: no one says james or ryan are lazy, the problem is almost nobody know what and when they are doing it. A downside is that it makes it hard to know how to help, We're far beyond trying to help them, at least for me, I just want to have ETA's and communication because this is how people work together. Their work (or absence of, or delays of, or ...) are impacting the work of every single DD out there, and that sucks. Do you want a Simple example ? For almost 4 or 5 months (if not more) there is no Alpha machine available to developers, one being restricted, the other in lock down, waiting for a setup I guess (-- did you remark the I guess ? I mean I don't know what's going on, and nobody knows afaict). The problem is, I'm now helping packaging the glibc, and we have a couple of alpha-only bugs. Things really stupid like headers problems, that would almost take a full minute to be fixed. BUt that bug fix is pending james, Ryan or a local admin work (again I've to guess), and nothing is coming, neither explanation on why no alpha machine is accessible, nor why it takes so long, nor an ETA. So what is _my_ reaction ? that I just don't give a damn about alpha, that bug will rot because: (1) there is nothing that I can do, and (2) and _THAT'S_ the real source of the frustration: I've no fucking clue of when it'll be fixed, and I'm tired polling db.debian.org to know when the fuck this machin will be up again. I've stopped doing so a couple of weeks ago, and I just erased alpha from my head. I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. If they don't understand it, then I for my part don't understand how they are in those critical positions in the first place. There is plenty of people out there that I'm sure have the same set of skills, maybe work 10% slower, but communicate and reduce the project frustration to 0 wrt core teams. So sorry, but I don't buy a single word of your argumentation here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSVH4WobJcv.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Pierre Habouzit [EMAIL PROTECTED] writes: I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. If they don't understand You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2007-02-23, Kalle Kivimaa [EMAIL PROTECTED] wrote: Pierre Habouzit [EMAIL PROTECTED] writes: I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. If they don't understand You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. But when is that going to happen ? somewhere between $NOW and when hell freezes over. not more detailed. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
also sprach Kalle Kivimaa [EMAIL PROTECTED] [2007.02.23.1054 +0100]: You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Does it say anywhere that this will be publicly accessible? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: Agalloch / Ashes Against the Grain signature.asc Description: Digital signature (GPG/PGP)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 11:54:40AM +0200, Kalle Kivimaa wrote: Pierre Habouzit [EMAIL PROTECTED] writes: I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. If they don't understand You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Why do you think this will make the teams communicate? Do you think lack of communication until now was entirely due to lack of an appropriate medium? I don't. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 11:54:40AM +0200, Kalle Kivimaa wrote: Pierre Habouzit [EMAIL PROTECTED] writes: I understand they cannot communicate about _everything_. But a downtime like that _is_ worth communicating. If they don't understand You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Our core teams not communicating is a social problem. RT is a technical solution. There are no technical solutions for social problems. I feel that RT is not a silver bullet, and adresses a non-issue in my opinion. I fear that its introduction will not help in solving the pressing issue that makes people stop caring about things. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns [EMAIL PROTECTED] wrote: incredibly open manner with a pretty impressive level of uptime. None of that means we can't or shouldn't be doing better, but I think it's worth recognising that when we say we're not doing a good enough job, *we* are still the ones setting and raising the bar. Others being even worse at that than we are is neither an excuse nor a compensation. Let's continue to raise the bar. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Pierre Habouzit a écrit : On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: On a personal note, in my experience the most effective way of working with James and Ryan is to trust that they generally know what they're doing and more or less leave them to get on with making things better on their own rather than hassling them for status reports or similar. Well, that leave one obvious question then, are they the best people for the job ? because I'd really prefer people that work 10% less, to communicate what they do in the other 90% of their task, so that everyone knows what's going on, and can plan their own job decently. My point is, many tasks in debian depend on what DSA/DAM/... do and especially when. Event if (for the sake of the argument) I admit that things get eventually done, the unknown time part _is_ generating a _lot_ of frustration. Just leave them to their own devices isn't something you'll see recommended in management books, but when people are doing stuff that they care about for fun, it's worth considering. This is just handwaving: letting them in their dark corner because they work faster like that, is not related to the issue that is debated: no one says james or ryan are lazy, the problem is almost nobody know what and when they are doing it. A downside is that it makes it hard to know how to help, We're far beyond trying to help them, at least for me, I just want to have ETA's and communication because this is how people work together. Their work (or absence of, or delays of, or ...) are impacting the work of every single DD out there, and that sucks. Do you want a Simple example ? For almost 4 or 5 months (if not more) there is no Alpha machine available to developers, one being restricted, The machine is locked since the compromise in July 2006. So that's almost *8 months*. the other in lock down, waiting for a setup I guess (-- did you remark the I guess ? I mean I don't know what's going on, and nobody knows afaict). The problem is, I'm now helping packaging the glibc, and we have a couple of alpha-only bugs. Things really stupid like headers problems, that would almost take a full minute to be fixed. BUt that bug Well the glibc in testing/unstable is not really a problem as it is currently frozen (though it would have been possible to release Etch without those bugs). The problem now concerns glibc 2.5 (or later) which will be the glibc for Lenny. I think the easiest solution is simply to *not* consider alpha as a release architecture for Lenny from the glibc point of view, and ignore bugs (but accept patches). After all this architecture fails one release criterion. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 11:41:06AM +0100, Marc Haber wrote: Our core teams not communicating is a social problem. RT is a technical solution. There are no technical solutions for social problems. That's not always true. Let's suppose (ad absurdum) that the questioned teams have their own .txt file in which they note the issues and their progress on them. An RT would change only in a minor way their way of working and at the same time (assuming the RT is public!) would reach the goal visibility we all are striving for. I personally do *not* think an RT would change anything. Still I don't see a valid reason for *not* trying. It's probably worst than other solutions I imagined when I read the subject of AJ's mail, but is probably better than nothing. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 10:44:55AM +0100, Pierre Habouzit wrote: So sorry, but I don't buy a single word of your argumentation here. It wasn't an argument; it was just a statement of things are, as I see them. In so far as how things are isn't well communicated in those areas, I don't see any other way of addressing that other than the above. We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 08:45:27PM +1000, Anthony Towns wrote: On Fri, Feb 23, 2007 at 10:44:55AM +0100, Pierre Habouzit wrote: So sorry, but I don't buy a single word of your argumentation here. It wasn't an argument; it was just a statement of things are, as I see them. In so far as how things are isn't well communicated in those areas, I don't see any other way of addressing that other than the above. We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. Given how gently help offers are treated, yes I'm beyond that. Blame yourself for that. That's also a very nice attempt to make me look bad and divert the discussion from its real matter. Sadly for you, I don't refuse to help, _you_ implied that I was part of a clever cabal to take over [EMAIL PROTECTED] So yes, awkwardly enough I don't consider helping DSA anymore, given what publicity I had in return. And like Marc said, when things in a project make people not care anymore, maybe the inherent problem is to be fixed, and not the people to be blamed. You don't fix a problem by hiding/blaming the symptoms. Thanks for caring. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTEryiuo0IU.pgp Description: PGP signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns aj@azure.humbug.org.au wrote: We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. So you think that from the project's point of view it is okay if nobody can expect basic support from core infrastructure teams? All we are allowed to consider with respect to these teams is to help *them*, not to achieve help? If yes, what is then the purpose of having infrastructure teams? If no, I cannot understand how you can answer like you did above. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: The primary reason why there's only one keyring-maint is the binary blob problem: [...] [...] This issue has been mentioned briefly in the past a few times, but to the best of my knowledge, no one's taken up the challenge so far. One of those mentions was in a mail to Branden as DPL in November 2005. I figure since I'm DPL now, it's fair game for me to quote the bits of that mail that don't go into any personal stuff: ] To: Branden Robinson / Debian Project Leader ] Subject: Re: keyring-maint assistance needed? ] From: James Troup ] Date: Tue, 22 Nov 2005 02:46:34 + ] ] [...] ] ] I think in the long term, keyring maintenance should obviously be done ] by more than one person. ] ] But I also think the ill-effects of forcibly or hurriedly adding ] additional maintainers vastly outweigh the ill-effects of its current ] one-man state. ] ] There's also a bunch of stuff that could be done, most of which is ] being worked on, that doesn't involve adding more people or have the ] problems associated with that. ] ] The three things most need to be worked on are: ] ] (a) spam. The keyring-maint address gets something like, ] conservatively, 500 spams for every non-spam email. This is ] after 4 layers of spam filtering. Thanks to Ryan's stellar work ] on our email infrastructure there are now options available to us ] that should allow us to drop this down to 0 spams (by requiring a ] specific tag in the subject, a pseudo-header in the body or a ] specific address to be used). ] ] (b) if/when (a) gets fixed[0], I'm going to look at setting up a ] Request Tracker instance to manage the keyring. Apart from ] helping me in terms of managing (and not losing track of) ] requests, it will also allow better transparency in terms of ] people being able to see how many and what requests are ] pending[1]. The only potential problem here is finding a ] suitable machine as RT is a big scary perl web app that can ] require a lot of resources. ] ] (c) right now changes to the keyring are fundamentally unauditable ] unless they're done by a single person on a trusted machine with ] trusted scripts. There are a bunch of ways to solve this, but ] the best suggestion I've heard so far is something that breaks ] down the 17Mb binary blob of 'debian-keyring.gpg' into single key ] auditable chunks that can then be managed in a sane way. The ] scripts to do these would have to be simple first and foremost so ] they could be audited. ] ] I'm working on (a) and (b) but I'm not working on (c) because I simply ] don't have time - others are of course welcome to. I've discussed the ] idea with several people in real life, and it's come up in the thread ] on -private. I also believe that with (a) and (b) done there is no ] pressing need for (c) although it'd obviously be nice to have. ] ] [...] ] ] -- ] James ] ] [0] RT sends auto-replies so it isn't an option as long as the email ] address is getting this much spam. ] ] [1] Although given the nature of some of the emails sent to ] keyring-maint things in the RT will be private by default and only ] public when they're moved to a public queue. I summarised this portion of the mail this time last year, too, fwiw: http://lists.debian.org/debian-vote/2006/03/msg00275.html Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/23/07, martin f krafft [EMAIL PROTECTED] wrote: also sprach Kalle Kivimaa [EMAIL PROTECTED] [2007.02.23.1054 +0100]: You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Does it say anywhere that this will be publicly accessible? Exactly Martin, if the plain is a publicly accessible interface to track requests for DSA, we've our BTS! The security argument sells the idea that a RT (not publicly accessible) would be better. That's why #408150 wasn't solved as i have requested. I don't see anyone opening a bug against a new debian-admin pseudo-package containing sensible information and the pseudo-package maintainers are smart enough to avoid add such thing in the answers, and it would be valid for public BTS or private RT anyway. If you disagree please answer with examples and remember that we've enough sensible information into our BTS (eg.: security issues in the softwares) and anyone is free to open bugs with debsecan output and stuff like that. Don't tell me that hey, what's the alpha machine status? and keyring-maint requests will leak information. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:14:34PM +0100, Stefano Zacchiroli wrote: I personally do *not* think an RT would change anything. Still I don't see a valid reason for *not* trying. One reason would be that we could do something more valuable with the same effort. I see parallels with what Bruce Schneier describes as cover your ass security in this article- http://www.wired.com/news/columns/0,72774-0.html Basically installing the RT tracker gives the appearance of doing something, and making everyone feel good about it, while achieving nothing. But maybe it will really work. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:57:01PM +0100, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. So you think that from the project's point of view it is okay if nobody can expect basic support from core infrastructure teams? I think we're talking about different things, so the following's a bit verbose in hopes that it makes it a bit clearer. If they don't do it, and it's important, someone else will. Cf the security team versus testing security support, backports or volatile versus ftpmaster, alioth versus DAM, or whatever. So yes, I do think it's okay even if we couldn't expect basic support from core infrastructure teams. All we are allowed to consider with respect to these teams is to help *them*, not to achieve help? You can reasonably expect them to do what they've said they will, or what the role obviously entails. You can also expect that every now and then you'll be disappointed and that won't be achieved, and that the only things you can really do about that is not worry about it and hope it's better next time, work out how to do it yourself, or figure out some way of helping them out. That's not what I was referring to though: I was talking about when you want someone else to do things in the way you'd like, rather than the way they prefer. That's something that only ever happens if you help out, whether you're talking about a user making suggestions to a maintainer, a maintainer making suggestions to upstream, or anything of the sort. You're not owed anything by people who freely donate their time to maintain things you use, it works better if you remember that. All I'm saying is it's a two-way process -- if you spend lots of time actually helping out someone, and they don't return the favour by helping you out, you shouldn't keep wasting your time. If yes, what is then the purpose of having infrastructure teams? If you don't have infrastructure teams you don't have infrastructure in the first place, well maintained or not... And if we didn't have useful infrastructure, someone would make it, and we'd have an infrastructure team. No purpose required... I don't think I understand the question. Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: softwares) and anyone is free to open bugs with debsecan output and stuff like that. Don't tell me that hey, what's the alpha machine status? and keyring-maint requests will leak information. Off the top of my head Please send the machine to my home address $ADDRESS - I'll drive out to the datacentre and put the machine on-line as soon as possible after I get it. Give the shipping company $NUMBER (my mobile phone number) as the contact number in case there are problems. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Feb 23, 2007 at 12:57:01PM +0100, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. So you think that from the project's point of view it is okay if nobody can expect basic support from core infrastructure teams? I think we're talking about different things, so the following's a bit verbose in hopes that it makes it a bit clearer. If they don't do it, and it's important, someone else will. That is a lie, at least in that general phrasing. If I ask Could someone please look into the buildd chroot on $foo and tell me whether ..., and the people who I asked and are able to do that will not do it, *nobody* will do it. The case of buildds also seems to prove the opposite, but I'm not going into that since too much issues are mixed there, and I'm not personally involved. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Feb 23, 2007 at 12:57:01PM +0100, Frank K?ster wrote: All we are allowed to consider with respect to these teams is to help *them*, not to achieve help? You can reasonably expect them to do what they've said they will, or what the role obviously entails. Obviously, being a buildd admin entails never answer any e-mails. Some admins have failed this requirement at times, but generally they fulfill it quite well. That's not what I was referring to though: I was talking about when you want someone else to do things in the way you'd like, rather than the way they prefer. That's something that only ever happens if you help out I'd like to have a point of contact for buildd issues. How can I help out when I have no means to get in contact with the people who are responsible for these issues? You're not owed anything by people who freely donate their time to maintain things you use, it works better if you remember that. We are not talking about what individual DDs can expect from core teams. I think we are talking what the project as a whole can expect. Moreover, the people who freely donate their time also give the impression of letting no one else do it. All I'm saying is it's a two-way process -- if you spend lots of time actually helping out someone, and they don't return the favour by helping you out, you shouldn't keep wasting your time. Like, trying to get packages built that fail in a way that seems to depend on the buildd environment, about which I know nothing? I should go a way and have a cup of coffee now, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/23/07, Mark Brown [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: softwares) and anyone is free to open bugs with debsecan output and stuff like that. Don't tell me that hey, what's the alpha machine status? and keyring-maint requests will leak information. Off the top of my head Please send the machine to my home address $ADDRESS - I'll drive out to the datacentre and put the machine on-line as soon as possible after I get it. Give the shipping company $NUMBER (my mobile phone number) as the contact number in case there are problems. That's up to the person behind the *my* you wrote, disclose $ADDRESS and $NUMBER. The same can't be said about our email address, so what's the point really? I don't think the DSA members will want to disclose this kind of information and if somebody does, they won't be forced to do so. Let me rewrite what would happen IRL, IMHO: Please send the machine to my home address - I'll drive out to the DC and put the machine on-line ASAP. Give the sipping company my phone number. I'll send you *my personal details* privately. I still disagree with a private tracking system for DSA. Almost all the information isn't sensible and can be there, the details can be passed privately and it's up to the message submitter and nobody else. It isn't like a person out of DSA can disclose sensible information that will put DSA stuff at risk. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
also sprach martin f krafft [EMAIL PROTECTED] [2007.02.23.1101 +0100]: You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Does it say anywhere that this will be publicly accessible? That was meant to be a genuine question, not hyperbole or whatever else you want to call it. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems science without religion is lame, religion without science is blind. -- albert einstein signature.asc Description: Digital signature (GPG/PGP)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Thanks, Anthony, for the update. I have some small comments inline below: As a consequence, if you have two people working on the keyring, and one hands the other a new version claiming that the only change is to include a new key for foo, it's very hard for the other maintainer to verify those are the only changes being made, or why they're being made if someone asks later. If keyring-maint A doesn't trust keyring-maint B to make authoritative decisions, then obviously one of them is not suitable for the team. You are highlighting auditing, and I wonder whether that's already in place. Does James keep log files and is it possible to verify that each change he makes is exactly the change he logs? If he does not, then adding more keyring maintainers wouldn't make any difference, would it? On a personal note, in my experience the most effective way of working with James and Ryan is to trust that they generally know what they're doing and more or less leave them to get on with making things better on their own rather than hassling them for status reports or similar. Just leave them to their own devices isn't something you'll see recommended in management books, but when people are doing stuff that they care about for fun, it's worth considering. There is a bottleneck, and if James and Joerg would both be rendered unable to attend to potentially urgent issues, the project would be stuck. You *will* see this as one of the prime concerns in most management books. I think I am understanding the gist of the complexity and trust issues involved with their positions. However, rather than saying that this is the way it is and we should just accept it, I think we should make every effort to prevent bottleneck problems *before* they arise. Your mail is an important step in that direction. I hope it will carry fruit. Thanks, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems if you see an onion ring -- answer it! signature.asc Description: Digital signature (GPG/PGP)
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns aj@azure.humbug.org.au wrote: If they don't do it, and it's important, someone else will. Cf the security team versus testing security support, backports or [...] That's fine if they don't do it. I think the problem is when they're doing it and make a mistake which they won't fix: how can anyone else fix it without some pretty ugly forking/competition? I think we do need basic support from core infrastructure teams. [...] You can reasonably expect them to do what they've said they will, or what the role obviously entails. You can also expect that every now and then you'll be disappointed and that won't be achieved, and that the only things you can really do about that is not worry about it and hope it's better next time, work out how to do it yourself, or figure out some way of helping them out. Not worrying about it isn't always a useful option; if it requires special permissions which only the person not fixing it can grant, you can't do it yourself; and if you try to help them (sending patches and so on), they may ignore the attempt. In other words, does the above combined with a DPL who won't appoint new people to underperforming teams mean: you're blocked; enjoy the free parking? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: [...lots of interesting info snipped...] * Wanna-build access - Ryan Murray, Steve Langasek, James Troup, Anthony Towns, others - schedule give-backs, binNMUs, etc - listed as group wb-$arch on DSA adminned machines (amd64 included in wb-i386, mipsel included in wb-mips) These groups don't have any real-life relevance anymore, AFAIK. They were important back when ftp-master.d.o was still accessible to any DD; but when ftp-master became a restricted host, they stopped getting updated. E.g., [EMAIL PROTECTED] also has access to the m68k wanna-build db, but is not in the right group. Currently, personally I don't even have a username on ftp-master.d.o (as is the case for none of the m68k buildd admins); all my wanna-build access goes through one of my buildd hosts. Most other stuff in your summary seems correct from my POV. [...] That's intended to be exhaustive and authoritative, but probably misses some bits that I'm not familiar with or that simply slipped my mind. That particularly applies to the buildd stuff, which I'm not really very familiar with, and have generally tried to avoid looking into in any depth. Glad to be of help :) [...] -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Anthony Towns wrote: I've been delaying this mail for a while now Is it purely coincidental that it was sent the same day as your nomination for the DPL elections? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 08:05:33PM +0100, Josselin Mouette wrote: Anthony Towns wrote: I've been delaying this mail for a while now Is it purely coincidental that it was sent the same day as your nomination for the DPL elections? Not remotely; I was delaying the nomination until I'd finished that mail (which I've been working on since end of January) and the trademark thing. Cheers, aj signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote:
On Fri, Feb 23, 2007 at 11:15:00PM -0500, Joey Hess wrote:
Changed-By: Joey Hess [EMAIL PROTECTED]
Comment: Removing an old email address.
I'm not sure that's plausible -- afaik the keyring gets synced to the
real keyservers for new signatures and uids, so removing addresses
doesn't work; though iirc you can do a revocation of a uid these days.
Sure, I just wanted to show it can be used for anything you'd do via
--edit-keys. I'm not sure what classes of changes keyring-maint
typically makes so it seemed best to cover all of them.
There should be some way of getting back to the original conversation
in case something goes wrong. I guess a field containing a URL to an rt
entry or similar would work?
Could be an url or even the whole message included, sure. I also left
out a Date field, which should be included.
Note that this is a relative changeset: its action depends on the
keyring it's run on, since it deletes uid 3 of 788A3F4C.
That means you can't reorder changesets easily. I wonder if it'd be
better say del uid [EMAIL PROTECTED] and have the tool work out
which uid (if any) that is.
I don't feel that reordering changesets is a good thing in general, since
it can lead to other problems (for example, reordering a key deletion to
come before a key addition), and it loses history that can be useful for
reviewing why and when a given change was made.
[EMAIL PROTECTED]:~cmp input.gpg TESTRING.gpg
[EMAIL PROTECTED]:~
Didn't you delete a uid as well as add and remove a key? Why aren't
there differences?
Because it's a review tool, so it's not intended to actually change the
input keyring. For that something like the attached would be used.
--
see shy jo
#!/usr/bin/perl
# Applies a changeset to a keyring.
use warnings;
use strict;
use File::Temp;
my @allowed_actions=qw(import edit-key delete-key);
my @gpgopts=qw(--command-fd 0 --no-auto-check-trustdb --no-default-keyring);
my $keyring=shift || usage();
my $changeset=shift || usage();
push @gpgopts, --keyring, $keyring;
my %fields;
my $field;
open(CHANGESET, , $changeset) || die $changeset: $!;
while (CHANGESET) {
chomp;
if (/^([^\s]+):(?:\s+(.*))?/) {
$field=lc $1;
if (defined $2) {
$fields{$field}=$2;
}
else {
$fields{$field}='';
}
}
elsif (/^\s+\.$/ defined $field) {
$fields{$field}.=\n;
}
elsif (/^\s+(.*)/ defined $field) {
$fields{$field}.=\n if length $fields{$field};
$fields{$field}.=$1;
}
elsif ($_ eq ) {
process() if defined $field;
%fields=();
}
else {
die parse error on line $. of $changeset;
}
}
close CHANGESET;
process() if defined $field;
sub process {
if (! exists $fields{action}) {
die $changeset missing action field;
}
my @action=split(' ', $fields{action});
my $command=shift @action;
if (! grep { $_ eq $command } @allowed_actions) {
die $changeset contains disallowed action \$command\;
}
if (! exists $fields{data}) {
die $changeset missing data field;
}
my $pid = open(GPG, |-);
$SIG{PIPE} = sub { die whoops, pipe broke };
if (! $pid) {
print gpg --$command @action\n;
exec(gpg, @gpgopts, --$command, @action) ||
die(failed to run gpg);
}
$|=1;
GPG-autoflush(1);
foreach my $line (split(\n, $fields{data})) {
print $line\n if $command ne 'import';
print GPG $line\n || die failed talking to gpg;
}
close GPG || die gpg exited nonzero;
print gpg operation complete\n\n;
}
sub usage {
die Usage: changeset-apply keyring changeset\n;
}
signature.asc
Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote: That means you can't reorder changesets easily. I wonder if it'd be better say del uid [EMAIL PROTECTED] and have the tool work out which uid (if any) that is. I don't feel that reordering changesets is a good thing in general, since it can lead to other problems (for example, reordering a key deletion to come before a key addition), and it loses history that can be useful for reviewing why and when a given change was made. I was more meaning it as an optimisation so you could ignore key add 0x7172daed if there was a key delete 0x7172daed changeset later. Likewise a uid add followed by a uid del or whatever. How would you convert gpg --refresh-keys into changeset based operations, I wonder? Maybe you could do it by something like: cp real-keyring.gpg tmpkeys.gpg gpg --keyring tmpkeys.gpg --refresh-keys for x in $(changed-keys); do ( echo Changed-By: me echo Comment: new signatures/uids for key $x echo Action: import --keyserver-options merge-only echo Data: gpg --keyring tmpkeys.gpg --ascii --armour --export $x | sed -e 's/^/ /' ) changeset-refresh-$x done rm tmpkeys.gpg echo Now you just have to apply changeset-refresh-* to real-keyring.gpg :) ? Cheers, aj signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote: I was more meaning it as an optimisation so you could ignore key add 0x7172daed if there was a key delete 0x7172daed changeset later. Likewise a uid add followed by a uid del or whatever. Ah, sure, as an optimisation it could be useful. However, I think that letting the keyring build tool operate in incremental mode during maintenance sessions (with one noninremental build at the end if desired) will make it fast enough. How would you convert gpg --refresh-keys into changeset based operations, I wonder? Maybe you could do it by something like: cp real-keyring.gpg tmpkeys.gpg gpg --keyring tmpkeys.gpg --refresh-keys for x in $(changed-keys); do ( echo Changed-By: me echo Comment: new signatures/uids for key $x echo Action: import --keyserver-options merge-only echo Data: gpg --keyring tmpkeys.gpg --ascii --armour --export $x | sed -e 's/^/ /' ) changeset-refresh-$x done rm tmpkeys.gpg echo Now you just have to apply changeset-refresh-* to real-keyring.gpg :) That's beautiful, if we can figure out what changed-keys is. :-) BTW, I have a keyring-explode script that does similar for converting an existing monlithic keyring into changesets. (attached) -- see shy jo #!/bin/sh # Converts a keyring into a bunch of changesets, one per key. # Only intended to be used for initial import of keyring. set -e if [ -z $1 ] || [ -z $2 ]; then echo Usage: keyring-expode keyring changesetdir 2 exit 1 fi keyring=$(readlink -f $1) # gpg works better with absolute keyring paths changesetdir=$2 basename=$(basename $keyring) mkdir -p $changesetdir touch $changesetdir/index for key in $(gpg --no-default-keyring --keyring $keyring --list-keys|grep '^pub' | sed -e 's!.*/!!' -e 's/ .*//'); do out=$changesetdir/add-$key echo $out echo Comment: extracted from $basename by keyring-explode $out echo Action: import $out echo Data: $out gpg --no-auto-check-trustdb --keyring $keyring -a --export $key | sed 's/^/ /' $out echo $(md5sum $out | cut -d -f 1) add-$key $changesetdir/index done signature.asc Description: Digital signature
Bits from the DPL: DSA and buildds and DAM, oh my!
Hey all, I've been delaying this mail for a while now, because I haven't been able to work out a way of writing it that doesn't strike me as not treating some of the concerns I've heard seriously enough. I still haven't come up with a way of avoiding that unfortunately, but it seems better to get something happening, even if it isn't really good enough. I'm trying to be descriptive here rather than prescriptive or proscriptive -- we've got a DPL campaign coming up where there'll be plenty of time to talk about various ways of improving things, so to me the most useful thing to do now seems to be providing a good understanding of how things are at the moment, and have an informed discussion over the next few weeks, rather than a repeat of all the arguments we've already had. So the first thing I'd like to note is that despite all the criticisms there are of things like new-maintainer, buildd administration, ftpmaster, system administration, and whatever else, objectively all of those areas are very impressive: compared to other distributions, we still have a huge number of contributors, we still support a huge number of architectures at an amazing level of quality, we still have a huge number of packages that are maintained at an amazingly high quality, we have a huge number of services that are administered in an incredibly open manner with a pretty impressive level of uptime. None of that means we can't or shouldn't be doing better, but I think it's worth recognising that when we say we're not doing a good enough job, *we* are still the ones setting and raising the bar. Okay, this is going to get really long, so if you've read this far and don't really care about any of the above areas, now's the time to skip to the next message and get on with your life. I think a good step is to cover what rights some of the more controversial roles actually have, as best I understand it. Again, this is just meant to be a description of what is, not necessarily what I think things should be, or was originally intended or anything else. * Debian Account Manager(s) (DAM) - Joerg Jaspert and James Troup - delegated authority to determine who is a developer - may only exercise this authority in cooperation with keyring-maint - have created assisting roles in the form of FrontDesk and Application Manager - nm.debian.org documents current progress of active applications - numerous amounts of documentation and sample reports around for what form applications should take * Debian System Administration (DSA) - James Troup, Martin Schulze (Joey), Ryan Murray, Phil Hands - delegated authority to determine official Debian services via delegation of debian.org subdomains - delegated authority to determine unofficial Debian services via delegation of debian.net subdomains - default administrators (root@) for machines donated to Debian - have created db.debian.org for tracking machines and accounts and controlling debian.net subdomains - listed as group adm on DSA adminned machines - have a repository for customised packages at deb-src http://db.debian.org/ debian-admin/ * System admin for host (root@host) - determined by owner/sponsor of hardware/bandwidth - responsible for security of machine - determines who is allowed access to host - determines what services are provided by host * Debian Archive Maintainer(s) (ftpmaster) - Ryan Murray, James Troup, Anthony Towns - responsible for maintianing the archive on ftp-master.debian.org - determines what may be accepted into the archive - determines the process by which software is accepted into the archive - listed as group debadmin on DSA adminned machines, have access to role user dak on DSA adminned machines - assisted by Joerg Jaspert, Jeroen van Wolffelaar, Randall Donald, Michael Beattie - ftpmaster and assistants are listed as group ftpteam on DSA adminned machines - maintain various bits of information about how the archive is administered at http://ftp-master.debian.org/ and have a developer-accessible mirror of the archive software on merkel.debian.org - BTS psuedopackage is http://bugs.debian.org/ftp.debian.org * Debian Kerying Maintainer (keyring-maint) - James Troup - responsible for maintaining the keyring containing public keys for all developers as used by DSA for db.debian.org, ftpmaster for the archive and others - provides http://keyring.debian.org/ interface to the keyring - maintains debian-keyring package - listed as group keyring on DSA adminned machines - assisted in the past by Michael Beattie - some procedures documented in section 3.2 of the developers reference and at http://keyring.debian.org/replacing_keys.html * Buildds... * Local admin of buildd
