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
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
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
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,
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
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
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
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,
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
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
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
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
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
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
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
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*
* 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
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
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
* 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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
62 matches
Mail list logo
