Question for all candidates

[Steve McIntyre]

Do we actually need a DPL? Would we be noticeably worse off without a DPL?

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray


signature.asc
Description: Digital signature

question for all candidates

[Marc 'HE' Brockschmidt]

Heya,

Two years ago, Branden Robinson talked about the issue of some tasks in
the project that are neither delegated by the Project leader nor covered
by the Constitution directly. [1] He referenced his platform from 2004
last year (when he was elected), but it seems that nothing has happened
since then.

So, to the question:
Should we amend our constitution to reflect how Debian is structured in
reality, or should the people doing these tasks now be recognized as
delegates of the DPL? What will you do to clarify the situation?

Marc

Footnotes: 
[1]  http://www.debian.org/vote/2004/platforms/branden#s2p4
-- 
BOFH #72:
Satan did it


pgp10kmKJyX2W.pgp
Description: PGP signature

Question for all candidates

[Mike Hommey]

Hi everyone,

If you had to summarize your platform with 3 keywords, what would they be ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A question for all candidates

[Rune B. Broberg]

(This may or may not be answered in your platforms)

Only one person can 'win' this election, meaning we'll have 3 candidates
remaining after this election. How will not getting elected affect your
work within Debian, and the goals you stated in your platforms?

-- 
Rune B. Broberg
Feel free to GPG-encrypt email sent to me.  Keyid: 0x87CD3DBD


pgpGunQjof6OJ.pgp
Description: PGP signature

Re: Question for all candidates

[Anthony Towns]

Steve McIntyre wrote:
Do we actually need a DPL? Would we be noticeably worse off without a DPL?
ObVious: We'd be violating the constitution not to have one; if we
refuse to elect one, we'll just have Manoj and Ian act as the DPL until
we work out what we want.
The general answer is, in my view, that we need some way of making 
decisions that can't be made by a single package maintainer, such as 
"who should be the maintainer of this package?" Even if we do that by 
writing some scripts, and forbidding anyone to change it -- we have to 
come up with /some/ answer; and the question is then what is the *best* 
answer?

Options other than a single DPL responsible for the entire project is to
have a committee much like Jeroen's Scud team. But committee's are
really hard to get right: sometimes they're too diverse and their
recommendations are a hodge-podge of incompatible ideas that are overly
complicated and unworkable; sometimes they end up having only one person
do any of the work, and then handicap that person with the formality of
approval by the rest of the committe; sometimes they waste everyone's
time in unproductive meetings; sometimes they get in the habit of
debating things internally and poeple who aren't on the committee don't
find out about what happens for months, and may never know why it happens.
Those are just fundamental properties of committees and teams in
general; while they can be absolutely brilliant when they're working
well, when they're not they can be truly, truly awful. I think it's
definitely an approach to work on -- but given our experience with the
technical committee's responsiveness or the SPI board's effectiveness, I
think we should be fairly wary of putting committees in leadership roles
within Debian.
Other options are to just have delegates doing the work and answerable
mostly to themselves; which some would argue is already the case. But
most of the people who do then go on to argue about how horrible this
is, and how it's destroying Debian; some sort of oversight really does
seem useful.
Direct democracy -- ie, solving problems by GR -- is another solution; I
think the level of debate and formalism that involves tends to be overly
political in all the bad ways, and suspect it's not something most of
the participants in Debian have the patience for.
Heck, I'm pretty impatient with the nine weeks that get spent on DPL
elections each year, personally...
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question for all candidates

[Steve McIntyre]

aj wrote:
>Steve McIntyre wrote:
>> Do we actually need a DPL? Would we be noticeably worse off without a DPL?
>
>ObVious: We'd be violating the constitution not to have one; if we
>refuse to elect one, we'll just have Manoj and Ian act as the DPL until
>we work out what we want.



Thanks; I wasn't sure whether anyone was going to respond. There is
more than a little devil's advocacy here - I'm quite convinced myself
that a DPL is necessary - but it'd be nice to see that all the
candidates can justify it.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A question for all candidates

[Rune B. Broberg]

(This may or may not be answered in your platforms)

Only one person can 'win' this election, meaning we'll have 3 candidates
remaining after this election. How will not getting elected affect your
work within Debian, and the goals you stated in your platforms?

-- 
Rune B. Broberg
Feel free to GPG-encrypt email sent to me.  Keyid: 0x87CD3DBD


pgp0.pgp
Description: PGP signature

Re: question for all candidates

[Ian Jackson]

Marc 'HE' Brockschmidt writes ("question for all candidates"):
> So, to the question:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognized as
> delegates of the DPL? What will you do to clarify the situation?

I'm not a candidate, but:

There seems to be no question here at all.  The delegate status was
always intended to cover (for example) the ftp administrators.  The
practical effect of this is that the Leader can fire (say) the release
manager.

I have heard some people claim that this is not the case and that
somehow some of the teams like the release and ftp teams are not
answerable to anyone.  This is patent nonsense.

Of course, the Leader should not needlessly annoy any of the delegate
teams.  For example, Branden said:
 `[the previous] project leader doesn't feel that the delegation
  process in our Constitution is the way Debian really works. He
  characterized a refusal to make delegates of the archive
  administrators, system administrators, and so forth as "pragmatic".'

I think the right way to interpret this is to see that many of the
people who do not agree about the constitutional position are doing a
good job anyway, and there is no need to rub their noses in it or
force them to lose a political battle.

Branden seemed to be suggesting that he would formally issue a
statement saying that certain people were delegates.  I think that
would have been a mistake.

The Leader should leave the situation in limbo unless they intend to
fire the current incumbents and have volunteers to replace them.  And
of course they should only do that if the incumbents need replacing,
which I don't think is currently the case with any of the teams I'm
aware of.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Jeroen van Wolffelaar]

On Mon, Feb 27, 2006 at 12:18:55PM +0100, Marc 'HE' Brockschmidt wrote:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognised as
> delegates of the DPL? What will you do to clarify the situation?

We should ensure that the document describing the organisational layout
of the project[1] is accurate. I can come into Ian Jackson's reply[2],
and I don't feel it is really needed to tackle this issue, as long as
the differences either way are mostly academic. I intend to focus on
real issues instead. When the difference is relevant, I will focus on
achieving what I want to achieve. As I wrote in my platform:

| [Debian] excels where people work together directly on technical
| problems they like to contribute to. It is the nature of the Debian
| project, and in the ideal situation, the DPL should not be involved at
| all.

What remains on the plate from the current term, is working with some of
those teams to get some bottlenecks and other issues resolved, but I do
not expect to need to (or that it would be effective to) resort to
powers only available for dealing with delegated teams, nor do I
currently consider any of the issues pressing enough to promise
working on them in my platform -- I will work on some of them, and
direct more attention when needed, but there are only so many hours in a
year, and I want to focus my DPL-ship.

--Jeroen

[1] http://www.debian.org/intro/organization
[2] http://lists.debian.org/debian-vote/2006/02/msg00679.html

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Bill Allombert]

On Mon, Feb 27, 2006 at 12:18:55PM +0100, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> Two years ago, Branden Robinson talked about the issue of some tasks in
> the project that are neither delegated by the Project leader nor covered
> by the Constitution directly. [1] He referenced his platform from 2004
> last year (when he was elected), but it seems that nothing has happened
> since then.
> 
> So, to the question:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognized as
> delegates of the DPL? What will you do to clarify the situation?

Thanks for your question.

The constitution does not require all task to be delegated. By my reading 
the constitution only require the DAM to be a Delegate, viz.

 8. The Project Leader's Delegates
 
   8.1. Powers
 
The Project Leader's Delegates:
 1. have powers delegated to them by the Project Leader;
 2. may make certain decisions which the Leader may not make directly,
including approving or expelling Developers or designating people
as Developers who do not maintain packages. This is to avoid
concentration of power, particularly over membership as a
Developer, in the hands of the Project Leader.

I don't plan to change the current situation in that matter.  If the
developers involved ask themself to become Delegates, I will certainly
consider it, but I am not sure it make any practical differences.

I think it is more useful and probably less confrontational to work
with them to enable them to perform their task smoothly and
transparently than arguing on technical constitutional points.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpBzqzs4M4Zu.pgp
Description: PGP signature

Re: Question for all candidates

[Steve McIntyre]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
>Hi everyone,
>
>If you had to summarize your platform with 3 keywords, what would they be ?

 * Communication
 * Standards
 * Training

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
There's no sensation to compare with this
Suspended animation, A state of bliss


signature.asc
Description: Digital signature

Re: Question for all candidates

[Jeroen van Wolffelaar]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
> If you had to summarize your platform with 3 keywords, what would they be ?

Communication, communication, communication.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question for all candidates

[Ted Walther]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:

If you had to summarize your platform with 3 keywords, what would they
be ?


Sourcecode, sex, and beer.

Ted

--
 It's not true unless it makes you laugh,   
but you don't understand it until it makes you weep.


Eukleia: Ted Walther
Address: 5690 Pioneer Ave, Burnaby, BC  V5H2X6 (Canada)
Contact: 604-430-4973


signature.asc
Description: Digital signature

Re: Question for all candidates

[Anthony Towns]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
> If you had to summarize your platform with 3 keywords, what would they be ?

I thought I already did: Vitality, Recruiting, Direction

Cheers,
aj



signature.asc
Description: Digital signature

Re: Question for all candidates

[Bill Allombert]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
> Hi everyone,
> 
> If you had to summarize your platform with 3 keywords, what would they be ?

If such a necessity were forced upon me, I would answer
"Liberté Égalité Fraternité". 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp6tD80b87Oa.pgp
Description: PGP signature

Re: Question for all candidates

[Frank Küster]

Bill Allombert <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
>> Hi everyone,
>> 
>> If you had to summarize your platform with 3 keywords, what would they be ?
>
> If such a necessity were forced upon me, I would answer
> "Liberté Égalité Fraternité". 

Hm.  So you mean we'd rather not reelect you, because in the second year
that would be replaced by "Liberté Égalité Guillotine"?

;-)

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: question for all candidates

[Andreas Schuldei]

* Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> [2006-02-27 12:18:55]:

> Two years ago, Branden Robinson talked about the issue of some tasks in
> the project that are neither delegated by the Project leader nor covered
> by the Constitution directly. [1] He referenced his platform from 2004
> last year (when he was elected), but it seems that nothing has happened
> since then.
> 
> So, to the question:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognized as
> delegates of the DPL? What will you do to clarify the situation?

I think the constitution is quite clear on what the DPL is allowed to
do and does not need amendment in this regard.

To me it does not make sense to delegate just for the sake of it. That
would feel bureaucratic to me and the project has already enough of
that. I would not go and delegate a d-i team, for example, since it
just works well anyway.

When important teams seem to be disfunctional or have a hard time to
find a structure that scales into the future I would however use my
powers of delegation to restructure the team from the outside. I would
only do that after I worked with the team to help it overcome it's
issues itself, however.

I followed both Martin Michelmayr's effords during his terms and
spend a lot of time in our DPL-team with some teams and would
like to continue this work as DPL to conclude it.


signature.asc
Description: Digital signature

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:

> When important teams seem to be disfunctional or have a hard time to
> find a structure that scales into the future I would however use my
> powers of delegation to restructure the team from the outside. I would
> only do that after I worked with the team to help it overcome it's
> issues itself, however.

If you were DPL right now, which teams would you consider making formal 
delegates regardless of their wishes?
-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-07 20:09:11]:
> > When important teams seem to be disfunctional or have a hard time to
> > find a structure that scales into the future I would however use my
> > powers of delegation to restructure the team from the outside. I would
> > only do that after I worked with the team to help it overcome it's
> > issues itself, however.
> 
> If you were DPL right now, which teams would you consider making formal 
> delegates regardless of their wishes?

It would depend on weather I had good additional people that
could make (in my oppinion) a difference in team dynamics and
performance.

Important teams I would watch in order of priority:
- Stable security
  There was a security blackout during the summer of 2005, with
  repercussions in the press and public oppinion, hurting the
  project.  
  Since then Moritz was added as a full member to the stable
  security team. Should the transition to common tracking tools,
  a devision between embargoed/unembargoed (vs stable/testing)
  and a more transparent and open work environment continue as it
  seems to present I dont see any need for any outside
  intervention.
  Given the high profile of Debian's security work I will follow
  the unfolding development closely, though.

- Keyring Mainainance
  The only person working on this is very busy. More redundancy
  and a more user-driven attitude could help a lot. I have been
  talking to the keyring maintainer on several occasions last year
  but we have not yet found a way or a candiate to help.
  Ideas? Nominations?

- Debian-System-Administrators
  The working climate in the team is lacking and communication
  internally and externaly can be improved. Some members are
  extremly busy. I would like the team to become able to add new
  manpower itself. I talked with three of the four admins on the
  phone numerous times during last term and would like to see
  change happening from the inside, first. Lacking that I would
  not wait much longer before intervening from the outside. I am
  certain that my election as DPL would help in that regard, as I
  was told before that since I was not DPL myself, I had no
  authority and could not help.

- FTP-Masters
  Transparency has improved and new people have been added.
  FTP-Masters have problems interacting with some other high
  profile, active developers, though.

- Press   
  Debian could do with an active, outgoing press department. I
  look for people with an outgoing personality, time, excellent
  english and experience with press. Packaging skills are less
  important. I would like local sub-departments with tight
  coordination with the "headquarter".
  Just very recently Alexander Schmehl was added to [EMAIL PROTECTED]
  That is a good step forward and we will follow closely, as with
  the security team.


signature.asc
Description: Digital signature

Re: question for all candidates

[Anthony Towns]

On Wed, Mar 08, 2006 at 03:34:33PM +0100, Andreas Schuldei wrote:
> - Keyring Mainainance
>   The only person working on this is very busy. More redundancy
>   and a more user-driven attitude could help a lot. I have been
>   talking to the keyring maintainer on several occasions last year
>   but we have not yet found a way or a candiate to help.
>   Ideas? Nominations?

So, since I have a pretty good relationship with James, I'm aware of
three instances of issues with key updates after revocations in the past
few months.

The first was Chip Salzenburg's request for a key update, subsequent
flaming over lack of responsiveness, and eventual resignation. AIUI,
Chip happened to make the request when James was particularly busy,
including increasingly demanding requests each day following that for a
week, and pestering James on work channels (#ubuntu-devel). Chip's key
updates were included in the next keyring update, unfortunately after that
had escalated into a flamewar on -devel, and Chip's resignation. The DPL
sent a request through to James about how that was handled, which James
responded to in some detail. To the best of my knowledge there was no
further followup from the DPL or the DPL team.

The second key replacement I'm familiar with was that of Simon Horms,
who (not long after Chip's resignation) /msg'ed me asking if I had any
idea if the replacement request he'd sent a couple of days earlier had
been received; I said that wasn't something I could check, and suggested
he /msg elmo with a polite request to see it had been received, since
keyring-maint tends to get buried under spam. I didn't hear anything
since, and ttbomk Horms was able to upload again pretty quickly.

The third was Andres Salomon; I prodded him about some random bug for
some random testing transition, and he replied that he couldn't do much
about it without his key getting replaced -- which he'd tried to get
done months ago. I spoke to James to see what was going on, he checked
his mailbox and found absolutely nothing about it. When I passed this
on to Andres, it turned out the mail requesting the update hadn't been
sent in the first place. That was rectified, and his key was updated
within a week or so.

In the mail to the DPL I mentioned above, James outlined three fairly
significant technical changes that could be implemented to make the
job easier, and could be done by anyone, without requiring any special
priveleges; and also noted why he doesn't believe it's technically
feasible to have the keyring maintained by multiple people, and how that
could be fixed.

So, I don't see how you can say how you "have not found a way to
help", and in all the cases I've seen, I don't think there's been any
significant problem in the way updates have been handled, at least on
the keyring-maint's behalf.

> - FTP-Masters
>   Transparency has improved and new people have been added.
>   FTP-Masters have problems interacting with some other high
>   profile, active developers, though.

We chatted about this on IRC at the beginning of October, to wit:

22:50  (i note you didn't come up with any specific problems in how 
ftpmaster's operating)
22:51  do you want to know?
22:51  why wouldn't i?
22:51  i asked, didn't i?
22:51  because you would perceive it as nagging.
22:51  huh?
22:52  lol
22:52  not???
22:52  i can send it in a mail if you want to
22:52  must run now.
22:52  the only thing i can think that would be nagging is if you're going 
   to say "stable updates taking a while", which doesn't strike me as 
   particularly exciting
22:53  sure, i can do that, then (c:

You didn't /msg me again until December, on a largely unrelated matter;
and never sent any email of that nature. Would you care to detail why
not, or what you or the DPL team were working on instead of communicating
your concerns to us?

In any event, it's very difficult to make improvements when people won't
tell you what the problems they see are, or don't find any improvement
to ever be good enough.

(The r1 update to sarge was delayed for a couple of reasons iirc; one
that I've forgotten, the other was due to the delay in the finalisation
of some fairly critical security updates for the kernel. The update
happened a couple of days after they were prepared, in spite of some
random problems coincidently caused by Horms' key replacement)

Cheers,
aj



signature.asc
Description: Digital signature

Re: question for all candidates

[Martin Schulze]

Andreas Schuldei wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-07 20:09:11]:
> > > When important teams seem to be disfunctional or have a hard time to
> > > find a structure that scales into the future I would however use my
> > > powers of delegation to restructure the team from the outside. I would
> > > only do that after I worked with the team to help it overcome it's
> > > issues itself, however.
> > 
> > If you were DPL right now, which teams would you consider making formal 
> > delegates regardless of their wishes?
> 
> It would depend on weather I had good additional people that
> could make (in my oppinion) a difference in team dynamics and
> performance.
> 
> Important teams I would watch in order of priority:
> - Stable security
>   There was a security blackout during the summer of 2005, with
>   repercussions in the press and public oppinion, hurting the
>   project.  

Err... you know that this was caused by disfunctional infrastructure
not maintained by the security team, right?

> - Press   
>   Debian could do with an active, outgoing press department. I
>   look for people with an outgoing personality, time, excellent
>   english and experience with press. Packaging skills are less
>   important. I would like local sub-departments with tight
>   coordination with the "headquarter".
>   Just very recently Alexander Schmehl was added to [EMAIL PROTECTED]
>   That is a good step forward and we will follow closely, as with
>   the security team.

Good input for the press team is always good - yet only very seldom
provided.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

Re: question for all candidates

[Don Armstrong]

On Thu, 09 Mar 2006, Anthony Towns wrote:
> In the mail to the DPL I mentioned above, James outlined three
> fairly significant technical changes that could be implemented to
> make the job easier, and could be done by anyone, without requiring
> any special priveleges; and also noted why he doesn't believe it's
> technically feasible to have the keyring maintained by multiple
> people, and how that could be fixed.

Could this mail (or the practical upshot of it) be made public?

[I've personally been interested in developing something along these
lines to deal with controlling the public keyrings that I seem to have
strewn througout mulitple machines, and it seems reasonable to attack
both issues at once, assuming I ever get time to do this.]


Don Armstrong

-- 
"Ban cryptography! Yes. Let's also ban pencils, pens and paper, since
criminals can use them to draw plans of the joint they are casing or
even, god forbid, create one time pads to pass uncrackable codes to
each other. Ban open spaces since criminals could use them to converse
with each other out of earshot of the police. Let's ban flags since
they could be used to pass secret messages in semaphore. In fact let's
just ban all forms of verbal and non-verbal communication -- let's see
those criminals make plans now!"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Kalle Kivimaa]

Anthony Towns  writes:
> In the mail to the DPL I mentioned above, James outlined three fairly
> significant technical changes that could be implemented to make the
> job easier, and could be done by anyone, without requiring any special
> priveleges;

What would these three things be? I might be interested in tackling
some of them.

-- 
* 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: question for all candidates

[Anthony Towns]

On Thu, Mar 09, 2006 at 01:35:05AM -0800, Don Armstrong wrote:
> On Thu, 09 Mar 2006, Anthony Towns wrote:
> > In the mail to the DPL I mentioned above, James outlined three
> > fairly significant technical changes that could be implemented to
> > make the job easier, and could be done by anyone, without requiring
> > any special priveleges; and also noted why he doesn't believe it's
> > technically feasible to have the keyring maintained by multiple
> > people, and how that could be fixed.
> Could this mail (or the practical upshot of it) be made public?

I'll leaving posting the mail itself to Branden or James if they chose,
since I only had a copy to comment on any wording that wasn't clear.

On Thu, Mar 09, 2006 at 11:47:18AM +0200, Kalle Kivimaa wrote:
> What would these three things be? I might be interested in tackling
> some of them.

So first one was the spam problem, keyring-maint is a well-known address,
and mails that are meant to go to it could be in all sorts of weird
formats. There's already magic debian.org handling that'll drop stuff
without a pseudo-header in the mail (for [EMAIL PROTECTED]), or without
a specific tag in the subject which should mostly solve the problem,
which mostly requires working out some tags/headers and making sure all
the appropriate documentation is updated.

The second was to get rt setup to, uh, track requests -- it's waiting
on the first thing (since rt sends auto-replies, and auto-replies to
spam is bad, mmmkay), and possibly also lacks a debian.org machine that can
be its host.

The third thing was to develop some new scripts to manage
debian-keyring.gpg in a more componentised manner -- rather than
one huge blob, have many small files that are independently auditable
(this is the key for "[EMAIL PROTECTED]", it's authorised because it came
via [EMAIL PROTECTED] after blah lost their key in a tragic accident
involving a watermelon, it's signed by foo and bar...). The scripts
to manage all this have to be simple, obviously correct and secure,
and also fast enough to be usable.

Apparently there's been some mention of this on -private; I'm not
sure when.

Cheers,
aj



signature.asc
Description: Digital signature

Re: question for all candidates

[Kalle Kivimaa]

[Moving this to -devel, please reply only there, this is not really
voting related stuff. We are talking about things to improve keyring
maintenance, for those not reading -vote.]

Anthony Towns  writes:
> So first one was the spam problem, keyring-maint is a well-known address,
> and mails that are meant to go to it could be in all sorts of weird
> formats. There's already magic debian.org handling that'll drop stuff
> without a pseudo-header in the mail (for [EMAIL PROTECTED]), or without
> a specific tag in the subject which should mostly solve the problem,
> which mostly requires working out some tags/headers and making sure all
> the appropriate documentation is updated.

Could these mails be required to have a valid GPG signature (either
for a key in a public keyserver or a DD key)? This would eliminate the
spam problem (almost) entirely.

> The third thing was to develop some new scripts to manage
> debian-keyring.gpg in a more componentised manner -- rather than
> one huge blob, have many small files that are independently auditable
> (this is the key for "[EMAIL PROTECTED]", it's authorised because it came
> via [EMAIL PROTECTED] after blah lost their key in a tragic accident
> involving a watermelon, it's signed by foo and bar...). The scripts
> to manage all this have to be simple, obviously correct and secure,
> and also fast enough to be usable.

I think I could at least try to tackle this, as this doesn't need
anything special. If somebody else is already working on this, I would
appreciate a heads-up :)

> Apparently there's been some mention of this on -private; I'm not
> sure when.

I recall some discussion, yes.

-- 
* 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: question for all candidates

[Jutta Wrage]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Am 08.03.2006 um 15:34 schrieb Andreas Schuldei:


- Stable security
  There was a security blackout during the summer of 2005, with
  repercussions in the press and public oppinion, hurting the
  project.


Shouldn't it be more: Looking that there will be no new release  
without security support for it up and running? Security support for  
Sarge was not the only problem, when Sarge was released...


greetings

Jutta

- -- 
http://www.witch.westfalen.de

http://witch.muensterland.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkQQimIACgkQOgZ5N97kHkc3ywCfciTShC1Ohb+GooQFV/cm3MlK
j5YAn06JqRMUjjrAVaoRE4l78Oi0byJN
=VO1l
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-07 20:09:11]:
>> If you were DPL right now, which teams would you consider making formal
>> delegates regardless of their wishes?
> 
> It would depend on weather I had good additional people that
> could make (in my oppinion) a difference in team dynamics and
> performance.

Last November, you and the DPL team wanted to propose a GR that would 
have forcibly made everyone in a position of authority a formal 
delegate, and stated that you had replacements ready if they were 
unwilling to comply.

1) You now appear less willing to do so. What has changed?

2) At the time you said that you had new ftp-masters and a new security 
team ready to replace the existing ones. Does this mean that you already 
have good additional people that could (in your opinion) make a 
difference in team dynamics and performance?

3) You have previously claimed that new people were formally delegated 
to the security team during the past year. This was never announced on 
debian-devel-announce, and these delegations were never posted on 
http://www.debian.org/intro/organization . If you were unable to 
successfully add people to teams then, why do you believe you would be 
able to do so during your time as DPL?

4) You were planning to propose a GR that would have made the
ftp-masters formal delegates. However, at the time you had not actually
raised this with the ftp-masters. How does this fit with your desire for 
the project to be more open and communicative?

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-09 20:39:20]:
> Last November, you and the DPL team wanted to propose a GR that would 
> have forcibly made everyone in a position of authority a formal 
> delegate, and stated that you had replacements ready if they were 
> unwilling to comply.

The GR was intended to clarify a situation that arose precisely
because Branden had talked with some ftp-masters. (So your
question 4) is not really valid.) Branden got told that he could
not delegate those old core teams since they pre-dated the
constituion and for that reason the constitution was not really
applicable to them. (This is of cause incorrect: the constitution
was ratified in a GR for the whole project. Other positions like
the DPL predate the constitution, too, and still they are very
much subject to it.) 

> 1) You now appear less willing to do so. What has changed?

The GR was intendet to clarify that point.
However, in a small oppinion poll I found that this apparently
was already clear to everyone in the project. A GR would not have
added much value but instead created unnecessary unrest and work

> 2) At the time you said that you had new ftp-masters and a new security 
> team ready to replace the existing ones. Does this mean that you already 
> have good additional people that could (in your opinion) make a 
> difference in team dynamics and performance?

At that time I emphazised several times that replacing the teams
was only the very last, desperate option, which we were trying to
avoid but for completeness sake had considered along with a
variety of less drastical ones.

I told you that we were trying to mediate, encourage
reconciliation, deescalate by getting different people to talk to
them, change the social setting to give them incentive to change,
etc.

The security team (which is in the process of restructuring
itself successfully) is actually a good example of how the adding
of a new member can help in several ways. Moritz
- does a lot of work, even on old stable software
- is open to new ways of working team oriented
- has time and dedication and ambition to improve the situation
- is willing to try to compensate for joey's "mail only" tracking
  by proxing into the issue tracking tools
- works tighly together with the much bigger and better
  testing-security team and channels their work into the stable
  team, even

I did not go after FTP-Master either. I was more worried about
DSA, which suffers badly under the social jam that you currrently
can witness and is paralysed by it. My current greatest hope is
that the good example of the security team can inspire it to
reform itself in a similar way. Actually the candiate that I
would suggest is also their prefered choice, they just cant get
to talk about it. I gave you his name, even.

> 3) You have previously claimed that new people were formally delegated 
> to the security team during the past year. This was never announced on 
> debian-devel-announce, and these delegations were never posted on 
> http://www.debian.org/intro/organization . If you were unable to 
> successfully add people to teams then, why do you believe you would be 
> able to do so during your time as DPL?

Yes. We had asked Joey to give some people access and priviliges
so that they could release kernel DSAs themselfs, quickly.
In the current framework this is not necessary any more for the
reasons given above.

My goal (now, as then) is to convince teams to take up new members
themselfs, as the security team did in the end. I think I am in
an excellent position to do so since I already spend a lot of
time talking to all involved parties and we covered a lot of
ground. 

During this conversation you yourself pointed out a major "flaw"
of my position at that time: I was not the DPL. This time around
I would be DPL when continuing to talk with these people, unlike
then, when I was only a DPL-team member.  With the body of
developers empowering me to lead these negotiations these teams
would know that the Debian Community was very much interested in
the reform of their teams for the better and would most likey
consider it very seriously.

> 4) You were planning to propose a GR that would have made the
> ftp-masters formal delegates. However, at the time you had not actually
> raised this with the ftp-masters. How does this fit with your desire for 
> the project to be more open and communicative?

Please see above. There had been talks and mails, even
face-to-face ones. People were informed of the intention to
delegate. Regarding not coming out with the GR out front,
irritating and potentially threatening them, was totally
intented. As written above I was interested to hear what my
fellow DDs thought and get feedback on it. The people were not
informed of the GR that never came to pass since they are overly
touchy and feel threatend quickly. Until you told them, that is.
(c:


signature.asc
Description: Digital signature

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-09 20:39:20]:
>> 1) You now appear less willing to do so. What has changed?
> 
> The GR was intendet to clarify that point.
> However, in a small oppinion poll I found that this apparently
> was already clear to everyone in the project. A GR would not have
> added much value but instead created unnecessary unrest and work

No, that doesn't make sense. Phrasing it like that makes it sound like 
the GR was intended to have no effect, but at the time you were willing 
to discuss the fact that it may be necessary to replace the existing 
ftp-masters and security team. In fact, you'd already planned for that.

>> 2) At the time you said that you had new ftp-masters and a new security 
>> team ready to replace the existing ones. Does this mean that you already 
>> have good additional people that could (in your opinion) make a 
>> difference in team dynamics and performance?
> 
> At that time I emphazised several times that replacing the teams
> was only the very last, desperate option, which we were trying to
> avoid but for completeness sake had considered along with a
> variety of less drastical ones.

No. Making somebody a constitutional delegate does precisely one thing - 
it gives the DPL the power to fire someone. It's hardly a secret that 
adopting a resolution that, in effect, says "The DPL should be able to 
fire the following people" is not something that encourages nice happy 
behaviour where everyone involves goes for naked swimming and saunas. 
It's a threat.

Now, it has been pointed out to you that threatening the people 
concerned would be likely to make them resign. In fact, it would have 
been an almost inevitable consequence of this GR. So saying that 
"replacing the teams was only the very last, desperate option" is 
somewhat disingenious - if you'd put forward that GR, you were going to 
have to replace the teams.

(As an aside, the London Metropolitan police have denied having a 
"shoot to kill" policy. They have a "shoot to incapacitate" policy. 
Further questioning has revealed that, in this context, "shoot to 
incapacitate" means "Unload your firearm into the suspect's head at 
close range". The aim is to incapacitate, but a near-inevitable 
consequence of the act is that the suspect is killed. You ought to be 
able to see the parallels)

> I told you that we were trying to mediate, encourage
> reconciliation, deescalate by getting different people to talk to
> them, change the social setting to give them incentive to change,
> etc.

You told me that you thought that that process had failed:

23:54  then he can find people who are able and willing to 
work together and delegate to them, if all else fails.
23:54  so far, pretty much all has failed.

Why do you now believe otherwise?

>> 3) You have previously claimed that new people were formally delegated 
>> to the security team during the past year. This was never announced on 
>> debian-devel-announce, and these delegations were never posted on 
>> http://www.debian.org/intro/organization . If you were unable to 
>> successfully add people to teams then, why do you believe you would be 
>> able to do so during your time as DPL?



> During this conversation you yourself pointed out a major "flaw"
> of my position at that time: I was not the DPL. This time around
> I would be DPL when continuing to talk with these people, unlike
> then, when I was only a DPL-team member.  With the body of
> developers empowering me to lead these negotiations these teams
> would know that the Debian Community was very much interested in
> the reform of their teams for the better and would most likey
> consider it very seriously.

At that time, the DPL made two (unreported) formal delegations to the 
security team. That didn't work. Why do you think they'd be any more 
likely to respond to you in your role as DPL?

>> 4) You were planning to propose a GR that would have made the
>> ftp-masters formal delegates. However, at the time you had not actually
>> raised this with the ftp-masters. How does this fit with your desire for 
>> the project to be more open and communicative?
> 
> Please see above. There had been talks and mails, even
> face-to-face ones. People were informed of the intention to
> delegate. Regarding not coming out with the GR out front,
> irritating and potentially threatening them, was totally
> intented. As written above I was interested to hear what my
> fellow DDs thought and get feedback on it. The people were not
> informed of the GR that never came to pass since they are overly
> touchy and feel threatend quickly. Until you told them, that is.
> (c:

Do you really think that it would have been wrong for people to consider 
the following as a threat?

20:04  this is the summary of the GR text that we think 
about:
20:04  he most serious of Debian's problems is that we have 
people in key
20:04  infrastructural positions who monopolize 
a

Re: question for all candidates

[Andreas Barth]

Hi,

* Matthew Garrett ([EMAIL PROTECTED]) [060310 14:42]:
> [...]

You reiterate things where Andreas clearly stated that you have
over-interpreted him.

What is the purpose of this? Do you have some personal issues with
Andreas Schuldei? Are you too unhappy that you didn't suceed in last
years election?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Andreas Barth <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> * Matthew Garrett ([EMAIL PROTECTED]) [060310 14:42]:
>> [...]
> 
> You reiterate things where Andreas clearly stated that you have
> over-interpreted him.

No. I reiterate things where Andreas has given misleading answers to 
direct questions (he repeatedly denies wanting to replace people, but 
attempted to get at least one person to take over elmo's position in 
ftp-master, for instance).

> What is the purpose of this? Do you have some personal issues with
> Andreas Schuldei? 

I believe that Andreas would make a bad (and, indeed, dangerous) DPL, 
and so am asking him questions that I believe he needs to answer. If the 
answers are satisfactory (which, so far, they haven't been) then I will 
revise my opinion of his suitability.

> Are you too unhappy that you didn't suceed in last years election?

That would be the one where I beat Andreas by a fairly large margin?
-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Barth]

* Matthew Garrett ([EMAIL PROTECTED]) [060310 16:25]:
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > * Matthew Garrett ([EMAIL PROTECTED]) [060310 14:42]:
> >> [...]
> > 
> > You reiterate things where Andreas clearly stated that you have
> > over-interpreted him.

> No. I reiterate things where Andreas has given misleading answers to 
> direct questions (he repeatedly denies wanting to replace people, but 
> attempted to get at least one person to take over elmo's position in 
> ftp-master, for instance).

I'm quite sure you can point out where he said that he wanted someone to
take over elmo's position in ftp-master.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Andreas Barth <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett ([EMAIL PROTECTED]) [060310 16:25]:
>> No. I reiterate things where Andreas has given misleading answers to 
>> direct questions (he repeatedly denies wanting to replace people, but 
>> attempted to get at least one person to take over elmo's position in 
>> ftp-master, for instance).
> 
> I'm quite sure you can point out where he said that he wanted someone to
> take over elmo's position in ftp-master.

Ok. Based on what we've discussed on IRC, you'll admit that Andreas
attempted to get at least one person to agree to take responsibility for
elmo's role as lead ftp-master without consulting elmo first? I think
the difference is largely semantic, but, well.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Jeroen van Wolffelaar]

On Thu, Mar 09, 2006 at 05:44:05PM +1000, Anthony Towns wrote:
> The first was Chip Salzenburg's request for a key update, subsequent
> flaming over lack of responsiveness, and eventual resignation. AIUI,
> Chip happened to make the request when James was particularly busy,
> including increasingly demanding requests each day following that for a
> week, and pestering James on work channels (#ubuntu-devel). Chip's key
> updates were included in the next keyring update, unfortunately after that
> had escalated into a flamewar on -devel, and Chip's resignation. The DPL
> sent a request through to James about how that was handled, which James
> responded to in some detail. To the best of my knowledge there was no
> further followup from the DPL or the DPL team.

Indeed, Chip also asked the DPL (team) about this repeatedly, and in my
humble opinion, a bit impatiently, requesting response times
disproportional to the issue at hand -- the key was presumed compromised
since at least June (when the story hit slashdot), but yet keyring-maint
was to the best of my knowledge contacted no earlier than October to get
a replacement key in.

I was asked by Branden to look into this, but before I actually came
around to really contact James Troup, after verifying proper procedures
were followed in the first place, Chip already resigned. Because I
didn't at that time and don't at present perceive any problem with
keyring-maint, I didn't want to bother James at all w.r.t. this
question. After all, as far as I can briefly see, the last >2 week gap
between keyring updates was a year ago, no updates between 25 Feb and 18
Mar 2005. Such track record is actually quite impressive. Kudos, James!

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Matthew Garrett <[EMAIL PROTECTED]> wrote:

> Last November, you and the DPL team wanted to propose a GR that would 
> have forcibly made everyone in a position of authority a formal 
> delegate, and stated that you had replacements ready if they were 
> unwilling to comply.

It's been pointed out to me that this isn't something that all of the 
DPL team were involved in, so I'd like to apologise for that. Most 
relevantly, I don't believe that Jeroen was pushing for this at all.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 13:41:29]:
> > The GR was intendet to clarify that point.
> > However, in a small oppinion poll I found that this apparently
> > was already clear to everyone in the project. A GR would not have
> > added much value but instead created unnecessary unrest and work
> 
> No, that doesn't make sense. Phrasing it like that makes it sound like 
> the GR was intended to have no effect, but at the time you were willing 
> to discuss the fact that it may be necessary to replace the existing 
> ftp-masters and security team. In fact, you'd already planned for that.

Me being a good organizer made it easy to for me to look ahead
and look at different outcomes and plan for the different
scenarios, in order to limit disruption and damage to the project
to a minimum. let me quote myself:

"At that time I emphazised several times that replacing the teams
was only the very last, desperate option, which we were trying to
avoid but for completeness sake had considered along with a
variety of less drastical ones."

> > At that time I emphazised several times that replacing the teams
> > was only the very last, desperate option, which we were trying to
> > avoid but for completeness sake had considered along with a
> > variety of less drastical ones.
> 
> No. Making somebody a constitutional delegate does precisely one thing - 
> it gives the DPL the power to fire someone.

The great majority of people I talked with considered the core
teams delegates already.

I would not think that delegates in Debian need to live with the
fear of being fired. It never happend before. Leaders are happy
if there are people who do the work. The idea of delegating to
someone in order to fire him is novel in itself and was certainly
not on our mind.

I would like to know if anyone else besides you ever got that
idea.

> > I told you that we were trying to mediate, encourage
> > reconciliation, deescalate by getting different people to talk to
> > them, change the social setting to give them incentive to change,
> > etc.
> 
> You told me that you thought that that process had failed:
> 
> 23:54  then he can find people who are able and willing to 
> work together and delegate to them, if all else fails.
> 23:54  so far, pretty much all has failed.
> 
> Why do you now believe otherwise?

Pigs can fly and the Security Team is changing. I like to believe
that the DPL team had a role in that. If it worked so well for
the security team, why do you think it should be impossible for
the other core teams? To be a leader reqires to have hope for the
future. I still have that and I will pursue those possible
scenarios that I belive hold most promise, trying to staying
clear of the destructive ones.

> At that time, the DPL made two (unreported) formal delegations to the 
> security team. That didn't work. Why do you think they'd be any more 
> likely to respond to you in your role as DPL?

Change is possibel. There is hope. See above. Besides: The goal
is not to delegate people forcibly into teams, it always has
been to stimulate jammed teams to reform themselfs.

> Do you really think that it would have been wrong for people to consider 
> the following as a threat?

you quote the very first draft of a GR that never came to past.
There was a second one and you yourself said it was much better.
Why do you paste here the first draft that I right
away admitted to have flaws? Why do you try to manipulate your
fellow DDs in such a way and did not even mention the second
version you liked?

> Let's be entirely clear here. You wanted to propose a GR that threatened 
> the existing ftp-masters, DSA and security team with being fired. You 
> didn't think that discussing this with the affected people in advance 
> was a good idea because they might have felt "threatened" because they 
> are "overly touchy".

Actually I have an irc log here where an FTP master admits to be
overly sensitive as soon as it comes to his office. Therefor I
tried to avoid a ruckus for their sake. 

If it is impossible to address certain topics or even covers up
questionably behaviour for others it is likely that one is caught
in a state of codependency. 

http://en.wikipedia.org/wiki/Codependency

Some people in Debian suffer from this already. The DPL must not
do that or he is unable to lead the project unimpared and is
unable to say or do some things that are unavoidable to help the
project overcome some of it's problems.

> Do you think that describing the security team, DSA and ftp-masters as 
> "overly touchy" brings harmony to Debian?

You seem a tad codependent.


signature.asc
Description: Digital signature

Re: question for all candidates

[Martin Schulze]

Andreas Schuldei wrote:
> Pigs can fly and the Security Team is changing. I like to believe
> that the DPL team had a role in that. If it worked so well for

It didn't have.

The changes were underway and in discussion independently.

> the security team, why do you think it should be impossible for
> the other core teams? To be a leader reqires to have hope for the
> future. I still have that and I will pursue those possible
> scenarios that I belive hold most promise, trying to staying
> clear of the destructive ones.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 13:41:29]:
>> No, that doesn't make sense. Phrasing it like that makes it sound like 
>> the GR was intended to have no effect, but at the time you were willing 
>> to discuss the fact that it may be necessary to replace the existing 
>> ftp-masters and security team. In fact, you'd already planned for that.
> 
> Me being a good organizer made it easy to for me to look ahead
> and look at different outcomes and plan for the different
> scenarios, in order to limit disruption and damage to the project
> to a minimum. let me quote myself:

Hang on a moment. You said "I found that this apparently was already 
clear to everyone in the project" (referring to the people concerned 
already being delegates). So, the GR should have had no effect at all, 
right? 

But that can't be true, because otherwise you wouldn't have needed to
consider the consequences of them refusing to accept these positions. In
fact, you'd considered that possibility to be sufficiently likely that
you'd actually gone to the effort of ensuring you had enough machines
available to build an entirely new Debian infrastructure. 

The basic truth is that you wanted this GR because you wanted it to be
possible to force the teams to do things when they didn't do what you
wanted, and you were fully aware that they would probably refuse. There 
is absolutely no other reason for wanting a GR on this issue.

>> No. Making somebody a constitutional delegate does precisely one thing - 
>> it gives the DPL the power to fire someone.
> 
> The great majority of people I talked with considered the core
> teams delegates already.

But they don't consider themselves delegates already. I think that's 
been discussed quite adequately already.

> I would not think that delegates in Debian need to live with the
> fear of being fired. It never happend before. Leaders are happy
> if there are people who do the work. The idea of delegating to
> someone in order to fire him is novel in itself and was certainly
> not on our mind.

The only difference between a delegate and a non-delegate is that
delegates can be fired if they don't do what the DPL or the rest of the
project like what they're doing. I put this to you in November, and you
didn't disagree. If you don't think that anyone would ever want to fire
them, why would you want to make them delegates?

>> You told me that you thought that that process had failed:
>> 
>> 23:54  then he can find people who are able and willing to 
>> work together and delegate to them, if all else fails.
>> 23:54  so far, pretty much all has failed.
>> 
>> Why do you now believe otherwise?
> 
> Pigs can fly and the Security Team is changing. I like to believe
> that the DPL team had a role in that. If it worked so well for
> the security team, why do you think it should be impossible for
> the other core teams? To be a leader reqires to have hope for the
> future. I still have that and I will pursue those possible
> scenarios that I belive hold most promise, trying to staying
> clear of the destructive ones.

So why did you appear to have no hope last November?

 they wont talk to me anymore

>> At that time, the DPL made two (unreported) formal delegations to the 
>> security team. That didn't work. Why do you think they'd be any more 
>> likely to respond to you in your role as DPL?
> 
> Change is possibel. There is hope. See above. Besides: The goal
> is not to delegate people forcibly into teams, it always has
> been to stimulate jammed teams to reform themselfs.

But you've already discussed forcibly adding people to teams - that's 
how this thread got started. You still haven't said how you expect that 
to work, given that the previous attempt failed.

>> Do you really think that it would have been wrong for people to consider 
>> the following as a threat?
> 
> you quote the very first draft of a GR that never came to past.
> There was a second one and you yourself said it was much better.
> Why do you paste here the first draft that I right
> away admitted to have flaws? Why do you try to manipulate your
> fellow DDs in such a way and did not even mention the second
> version you liked?

Because the two drafts carried the same meaning, even though the 
language was different. You admitted that you felt the first draft was 
non-ideal, but you didn't appear to disagree with it. The message was 
very clear - you believed that certain teams within the project were not 
accountable to the project leader, and you wanted them to be made 
accountable so that they could be forced to do what the DPL wanted them 
to do. No matter how you word that, it's a threat. It's "Behave 
yourself, or you'll be overruled". It's not a nice thing to do.

>> Let's be entirely clear here. You wanted to propose a GR that threatened 
>> the existing ftp-masters, DSA and security team with being fired. You 
>> didn't think that discussing this with the affecte

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 15:58:15]:

> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > * Matthew Garrett ([EMAIL PROTECTED]) [060310 16:25]:
> >> No. I reiterate things where Andreas has given misleading answers to 
> >> direct questions (he repeatedly denies wanting to replace people, but 
> >> attempted to get at least one person to take over elmo's position in 
> >> ftp-master, for instance).
> > 
> > I'm quite sure you can point out where he said that he wanted someone to
> > take over elmo's position in ftp-master.
> 
> Ok. Based on what we've discussed on IRC, you'll admit that Andreas
> attempted to get at least one person to agree to take responsibility for
> elmo's role as lead ftp-master without consulting elmo first? I think
> the difference is largely semantic, but, well.

Part of the effords to determine what option there were I asked
Anthony Towns if he could take the lead in the ftp-master team.
The intention was not to remove James from the team and loose his
expertise but to unload him. That is what I said in the same irc
conversation, too, but you fail to quote that.

You are malicious on purpose, even. For example you quote the
very first ad-hoc draft, not the reworded one, which you said was
quite good. Why?

You are on a witch hunt. Stop it. I am not evil. 

The only thing you manage to do is to demonstrate that I have
been very active during the year, talked to a lot of people,
looked at all conceivable options and discussed them with people
even outside the DPL team. Long before you and me talked on irc I
had several phone conversations with James and Joey to learn more
about the situation first hand. Have you done that, too? 

Among other things I asked James what he thought could be done if
the team-internal reconciliation attempts that he wanted to
undertake (and by now even started) would fail and told him also
about the different escalation scenarios that I could imagine.
As far as I can recall we talked about three different options.
The best and most desireable one was reconciliation within the
team, enabling it to take up new members again (which james
himself wants, too, btw). I can't recall the middel scenario
right now.  The worst case option that we talked about was the
implementation of a parallel infrastructure, run by an other
team. He was cool about that. It was clear to us both that it we
did not want this to happen and instead hoped (and worked) for
the reconciliation.

That was shortly after debconf, in august at latest. We were in
contact several times since then and usually he promised to write
the email to joey or calling him about getting together and
talking right after the phone call. Every time he was extremly
busy and had lots of things to do.

The conversation where i asked aj if he would consider serving as
head ftp-master and unload (not fire!) james was in oct 5th.

You and me talked in November, when still no attempt from james
had been made to contact joey about this.

i hope this puts your worries and this thread to rest.


signature.asc
Description: Digital signature

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 15:58:15]:
>> Ok. Based on what we've discussed on IRC, you'll admit that Andreas
>> attempted to get at least one person to agree to take responsibility for
>> elmo's role as lead ftp-master without consulting elmo first? I think
>> the difference is largely semantic, but, well.
> 
> Part of the effords to determine what option there were I asked
> Anthony Towns if he could take the lead in the ftp-master team.
> The intention was not to remove James from the team and loose his
> expertise but to unload him. That is what I said in the same irc
> conversation, too, but you fail to quote that.

I didn't claim that there was an attempt to remove James from the team. 
I claimed that there was an attempt to remove responsibilities from him 
without asking him beforehand.

> You are malicious on purpose, even. For example you quote the
> very first ad-hoc draft, not the reworded one, which you said was
> quite good. Why?

Because it's the one I have the text of, and because they're 
semantically equivalent.

> You are on a witch hunt. Stop it. I am not evil. 

Oh, I don't believe you're evil (despite you joking about wanting to
have me physically beaten because you didn't like an email I sent). I 
just believe that having you as DPL would be a bad thing.

> The only thing you manage to do is to demonstrate that I have
> been very active during the year, talked to a lot of people,
> looked at all conceivable options and discussed them with people
> even outside the DPL team. Long before you and me talked on irc I
> had several phone conversations with James and Joey to learn more
> about the situation first hand. Have you done that, too? 

No, but I did spend a great deal of time trying to talk you out of
things I thought were harmful and trying to convince people not to quit
the project because of things you were proposing to do. I acknowledge 
that you've spent a great deal of time and effort on Debian in the past 
year.

(How many of last year's DPL team are willing to serve again with you as 
DPL?)
-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Barth]

* Matthew Garrett ([EMAIL PROTECTED]) [060310 16:58]:
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > * Matthew Garrett ([EMAIL PROTECTED]) [060310 16:25]:
> >> No. I reiterate things where Andreas has given misleading answers to 
> >> direct questions (he repeatedly denies wanting to replace people, but 
> >> attempted to get at least one person to take over elmo's position in 
> >> ftp-master, for instance).
> > 
> > I'm quite sure you can point out where he said that he wanted someone to
> > take over elmo's position in ftp-master.
> 
> Ok. Based on what we've discussed on IRC, you'll admit that Andreas
> attempted to get at least one person to agree to take responsibility for
> elmo's role as lead ftp-master without consulting elmo first? I think
> the difference is largely semantic, but, well.

Quite interessting that you sent out that mail a few minutes after I
told you I'm going away from my computer. Well done.

Anyways, I disagree with that statement. If your cited sentence is
correct, Andreas has investigated whether someone (and you refused to
tell who, it might be even someone in the role of an ftp-master) might
be interessted in becoming lead ftp-master without asking James Troup
for permission first for that investigation. As far as I know James, it
is possible to speak with other people about solutions without offending
him.  And I can understand if Andreas makes a first research round
without asking James about each candidate first - if there seems to be a
competent and willing candidate available, there is still enough time to
discuss that with James. And it is really something quite different
whether one "attempt to get someone to take over elmo's position" (in
other words, hijack that), or whether he investigates whether there is
someone else who is both competent and interessted, and then try to get
a common agreement.

Oh, BTW, I hope I didn't do anything equally wrong for you when I talked
to Anthony today about stable point releases on an IRC channel where
James wasn't present. I know that James doesn't really mind, but you
might.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Matthew Garrett]

Andreas Barth <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett ([EMAIL PROTECTED]) [060310 16:58]:
>> Ok. Based on what we've discussed on IRC, you'll admit that Andreas
>> attempted to get at least one person to agree to take responsibility for
>> elmo's role as lead ftp-master without consulting elmo first? I think
>> the difference is largely semantic, but, well.
> 
> Quite interessting that you sent out that mail a few minutes after I
> told you I'm going away from my computer. Well done.

Your complaint was over the fact that you interpreted "replace" as 
meaning elmo would no longer be an ftp-master. I clarified that.

> Anyways, I disagree with that statement. If your cited sentence is
> correct, Andreas has investigated whether someone (and you refused to
> tell who, it might be even someone in the role of an ftp-master) might
> be interessted in becoming lead ftp-master without asking James Troup
> for permission first for that investigation. 

Correct. Or, as I said, "Andreas attempted to get at least one person to
agree to take responsibility for elmo's role as lead ftp-master without
consulting elmo first"

> As far as I know James, it is possible to speak with other people
> about solutions without offending him.  And I can understand if
> Andreas makes a first research round without asking James about each
> candidate first - if there seems to be a competent and willing
> candidate available, there is still enough time to discuss that with
> James. And it is really something quite different whether one "attempt
> to get someone to take over elmo's position" (in other words, hijack
> that), or whether he investigates whether there is someone else who is
> both competent and interessted, and then try to get a common
> agreement.

No, I think it's entirely unacceptable to start asking around for people 
willing to take over someone's responsibilities without first checking 
if they're willing to relinquish them. It's a clear statement that you 
don't think they're performing their duties well enough.

> Oh, BTW, I hope I didn't do anything equally wrong for you when I talked
> to Anthony today about stable point releases on an IRC channel where
> James wasn't present. I know that James doesn't really mind, but you
> might.

Not at all. However, I should probably point out that I'll be doing your 
job as a member of Andreas's DPL team now. I've decided that you simply 
aren't good enough at it, and someone on IRC suggested that I'd do a 
better job than you. You're welcome to hang around, but all the 
difficult stuff is up to me now. Hope you don't mind.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[martin f krafft]

also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.10.2250 +0100]:
> > Pigs can fly and the Security Team is changing. I like to believe
> > that the DPL team had a role in that. If it worked so well for
> 
> It didn't have.
> 
> The changes were underway and in discussion independently.

Not trying to pick on anyone here, but the DPL team came into play
and I sparked the Oldenburg security meeting idea, and *then* things
started moving. If they'd been underway long before, I wouldn't be
able to tell because noone was informed.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"there are lots of reasons not to use linux.
 there just aren't any good ones."
 --steven j. vaughan-nichols


signature.asc
Description: Digital signature (GPG/PGP)

Re: question for all candidates

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.10.2250 +0100]:
> > > Pigs can fly and the Security Team is changing. I like to believe
> > > that the DPL team had a role in that. If it worked so well for
> > 
> > It didn't have.
> > 
> > The changes were underway and in discussion independently.
> 
> Not trying to pick on anyone here, but the DPL team came into play
> and I sparked the Oldenburg security meeting idea, and *then* things
> started moving. If they'd been underway long before, I wouldn't be
> able to tell because noone was informed.

Wrong.

The security team has discussed issues internally long before some
people met in Oldenburg.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 22:27:51]:
> (How many of last year's DPL team are willing to serve again with you as 
> DPL?)

I dont know, really. All that I asked would like to be on my DPL
team next term. Those were Steve and Enrico. 

I did not ask Joeren for obvious reasons. 

Bdale is a busy man and eventhough I would like to see him as a
"continuos guest" on the team, providing insight and councel when
he is there, I think that his schedule does not allow him to
engage himself as deeply as I would hope to see it from a full
member. 

Same goes for Mako.

I did not consider asking Branden because he seems to need a
timeout.


signature.asc
Description: Digital signature

Re: question for all candidates

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:

> I did not ask Joeren for obvious reasons. 

What were those obvious reasons? You and Branden stood against each 
other despite agreeing to be on each other's team, so I'm curious as to 
why the same isn't true this year.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Andreas Schuldei]

* Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 23:23:52]:

> Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> 
> > I did not ask Joeren for obvious reasons. 
> 
> What were those obvious reasons? You and Branden stood against each 
> other despite agreeing to be on each other's team, so I'm curious as to 
> why the same isn't true this year.

It came as a surprise to me to have a contender in my own team
when I returned from my skiing vacation last year. I did not want
a similar situation this year again. 

I guess if I win this year and think Joeren could complement my
team with a skill it was still lacking I would ask him.

The good thing about our voting system is that you cant split
votes. By running seperatly (and both being team based) we give
people a wider choice of candiates with teams. That is a good
thing since everyone who thinks he can do this alone without
being just a figure head fools himself and the whole Debian
project. Both he and I understood that and can provide a real
choice to the voters.


signature.asc
Description: Digital signature

Re: question for all candidates

[martin f krafft]

also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.11.0010 +0100]:
> > > It didn't have.
> > > 
> > > The changes were underway and in discussion independently.
> > 
> > Not trying to pick on anyone here, but the DPL team came into play
> > and I sparked the Oldenburg security meeting idea, and *then* things
> > started moving. If they'd been underway long before, I wouldn't be
> > able to tell because noone was informed.
> 
> Wrong.

How can any of the above be wrong? Maybe I failed to make it
explicit that *it seemed to me* (and not only me) that things
started moving only after...

> The security team has discussed issues internally long before some
> people met in Oldenburg.

This is exactly one example where more transparency could benefit
all involved.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"most people become bankrupt through having invested too heavily in
 the prose of life. to have ruined one's self over poetry is an
 honour."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: question for all candidates

[Anthony Towns]

On Sat, Mar 11, 2006 at 01:05:06AM +0100, Andreas Schuldei wrote:
> That is a good
> thing since everyone who thinks he can do this alone without
> being just a figure head fools himself and the whole Debian
> project. Both he and I understood that and can provide a real
> choice to the voters.

Do you think the other candidates will be trying to "do this alone"?

There are a few reasons to dislike the "DPL team" concept without going
it alone; such as the liklihood of formal membership making it difficult
for non-members to contribute in the same way members do, or the way that
making the team be an issue at election-time tends to politicise it --
if Steve and Andi are working with you, does that mean they're working
against me or Joroen? The technical committee has a policy (written into
the constitution, no less!) of doing all its deliberations in the open [0],
while the DPL team over the past year seems to have operated quite privately,
if not secretively.

At the very least, with no action required on their part at all,
whoever is elected DPL will have the technical committee, dozens of
infrastructure maintainers, and hundreds of developers, new maintainers
and other contributors ready to offer advice and assistance.

Cheers,
aj

[0] http://lists.debian.org/debian-ctte/2006/03/msg00065.html



signature.asc
Description: Digital signature

Re: question for all candidates

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.11.0010 +0100]:
> > > > It didn't have.
> > > > 
> > > > The changes were underway and in discussion independently.
> > > 
> > > Not trying to pick on anyone here, but the DPL team came into play
> > > and I sparked the Oldenburg security meeting idea, and *then* things
> > > started moving. If they'd been underway long before, I wouldn't be
> > > able to tell because noone was informed.
> > 
> > Wrong.
> 
> How can any of the above be wrong? Maybe I failed to make it
> explicit that *it seemed to me* (and not only me) that things
> started moving only after...

You wrote "and then things started moving", which is wrong because
restructuring the security team was already in discussion and part
of it already implemented.

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Raphael Hertzog]

On Sat, 11 Mar 2006, Anthony Towns wrote:
> There are a few reasons to dislike the "DPL team" concept without going
> it alone; such as the liklihood of formal membership making it difficult
> for non-members to contribute in the same way members do, or the way that
> making the team be an issue at election-time tends to politicise it --
> if Steve and Andi are working with you, does that mean they're working
> against me or Joroen?

Certainly not. I have accepted to be on Andrea's team because I want to
help Debian and had no particular reason to refuse his invitation (even if
I don't think that stockholm would do the best DPL). 

But I will certainly offer my help to another DPL like Steve and you.

> The technical committee has a policy (written into
> the constitution, no less!) of doing all its deliberations in the open [0],
> while the DPL team over the past year seems to have operated quite privately,
> if not secretively.

That's right, and this really needs to change. But this thread explains
partly why many things got done privately ... and with another approach
I'm convinced that we can do better.

Single DPL or DPL team, both have pros and both have cons.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Adeodato Simó]

* Raphael Hertzog [Sat, 11 Mar 2006 10:06:01 +0100]:

> (even if I don't think that stockholm would do the best DPL). 

  Is this a statement, or an hypothesis? If a statement, then I feel
  compelled to ask: who would?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Andrés Calamaro - Mi Propia Trampa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Jeroen van Wolffelaar]

On Thu, Mar 09, 2006 at 08:39:20PM +, Matthew Garrett wrote:
> Last November, [Andreas] and the DPL team wanted to propose a GR that
> would have forcibly made everyone in a position of authority a formal
> delegate, and stated that you had replacements ready if they were 
> unwilling to comply.

I'd like to emphasise, as you later noted, that this was not something
the DPL team wanted. Andreas discussed this within the DPL team, and I
told Andreas in November very clearly that I thought it was a very bad
idea.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Jeroen van Wolffelaar]

On Sat, Mar 11, 2006 at 01:05:06AM +0100, Andreas Schuldei wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-10 23:23:52]:
> > Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> > > I did not ask Joeren for obvious reasons. 
> > What were those obvious reasons? You and Branden stood against each 
> > other despite agreeing to be on each other's team, so I'm curious as to 
> > why the same isn't true this year.
> 
> It came as a surprise to me to have a contender in my own team
> when I returned from my skiing vacation last year. I did not want
> a similar situation this year again. 

This year, team formation is happening after nominations are already
over, so your fear makes no sense.

Within the DPL team, I discussed at the beginning of the nomination
period who would run this year. I announced that I would most likely
nominate myself. Why didn't you inform the rest of the team you were
considering to run again until you nominated yourself publicly? That was
a surprise for me.

> The good thing about our voting system is that you cant split
> votes. By running seperatly (and both being team based) we give
> people a wider choice of candiates with teams. That is a good
> thing since everyone who thinks he can do this alone without
> being just a figure head fools himself and the whole Debian
> project. Both he and I understood that and can provide a real
> choice to the voters.

I don't understand, identical teams or not, there would've been two
candidates with a team? Are the other five candidates all fools, or
running to become a figure head? 

If that's what you wanted to write, I strongly disagree.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Raphael Hertzog]

On Sat, 11 Mar 2006, Adeodato Simó wrote:
> * Raphael Hertzog [Sat, 11 Mar 2006 10:06:01 +0100]:
> 
> > (even if I don't think that stockholm would do the best DPL). 
> 
>   Is this a statement, or an hypothesis? If a statement, then I feel
>   compelled to ask: who would?

It's a statement that I will not rank stockholm first this year (given
everything I've seen and given my own feelings). Of course, not a single
candidate is perfect, so it depends on the criterion used to differentiate
them.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question for all candidates

[Steve Langasek]

On Fri, Mar 10, 2006 at 10:26:47PM +0100, Andreas Schuldei wrote:

> > > At that time I emphazised several times that replacing the teams
> > > was only the very last, desperate option, which we were trying to
> > > avoid but for completeness sake had considered along with a
> > > variety of less drastical ones.

> > No. Making somebody a constitutional delegate does precisely one thing - 
> > it gives the DPL the power to fire someone.

> The great majority of people I talked with considered the core
> teams delegates already.

> I would not think that delegates in Debian need to live with the
> fear of being fired. It never happend before. Leaders are happy
> if there are people who do the work. The idea of delegating to
> someone in order to fire him is novel in itself and was certainly
> not on our mind.

> I would like to know if anyone else besides you ever got that
> idea.

Er, I raised this exact objection when these "clarification" delegations
were being discussed.  It was clear from the context, and from what *roles*
people were looking to have delegated, that this was an attempt to exercise
control over certain "problematic" teams: even though the release team
occupies the same ambiguous status in Debian of never having been a formal
DPL delegation, all of the focus was on delegating teams like the security
team because there's a public perception that the release team works well
and that the security team doesn't.

And since the only real control delegation gives is the power of the DPL to
dismiss the delegate, it's not a stretch for someone to think that making
someone a delegate in an area they're already responsible for means you
*want* to fire them.  I cautioned that delegation was only relevant to
improving the functioning of these teams if the plan was to replace the
current team members.

Ultimately, though, it seems we in fact *don't* want to fire these teams,
since this GR didn't come to pass.

-- 
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/


signature.asc
Description: Digital signature

Question for all candidates: Release process

[Russ Allbery]

This is for all candidates.

Releasing is regularly the hardest thing that Debian does, not just
technically but also socially.  Apart from the standard issues of setting
deadlines, RC bug counts being high, and similar difficult technical
issues, the process seems to eat volunteers.  There's usually always at
least some frustration, anger, and upsetness, and there seems to usually
be at least one resignation over the course of a release, often in a way
that hurts other activities in Debian for a time.

Do you have any ideas how, as DPL, you would (or even could) address this?
I'm personally the most concerned with the social issues.  A delayed
release can be frustrating but doesn't have that much negative impact, but
volunteers with enough knowledge of Debian to be able to serve as release
managers or helpers are rare.  And usually the arguments not only hurt
their contributions to Debian but usually hurt the contributions to Debian
of the people on the other side of the argument as well, who are often
also valuable and difficult-to-replace volunteers.

Do you have any thoughts about how to resolve release issues with less
hurt and negative impact to the project all around?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9ushn4@windlord.stanford.edu

Re: A question for all candidates

[Branden Robinson]

On Wed, Feb 26, 2003 at 02:27:16PM +0100, Rune B. Broberg wrote:
> Only one person can 'win' this election, meaning we'll have 3 candidates
> remaining after this election. How will not getting elected affect your
> work within Debian, and the goals you stated in your platforms?

I've largely limited the scope of my Platform this year to those things
which the DPL is uniquely or best empowered to accomplish.  Therefore,
if I am not elected, some of those things may go undone.

Whether I am elected or not, I will be continuing to work within the
Project as a package maintainer.  I am currently trying to groom some
co-maintainers for XFree86, for example.  :)

-- 
G. Branden Robinson|   Psychology is really biology.
Debian GNU/Linux   |   Biology is really chemistry.
[EMAIL PROTECTED] |   Chemistry is really physics.
http://people.debian.org/~branden/ |   Physics is really math.


pgpKaKZc1Xk7U.pgp
Description: PGP signature

Re: A question for all candidates

[Bdale Garbee]

[EMAIL PROTECTED] (Rune B. Broberg) writes:

> Only one person can 'win' this election, meaning we'll have 3 candidates
> remaining after this election. How will not getting elected affect your
> work within Debian, and the goals you stated in your platforms?

I will continue to work for Debian regardless of how this election turns out.

Since none of the other candidates presents a vision for how Debian should
grow and evolve that conflicts with the ideas I presented, I hope these
ideas will be carried forward by the project no matter who gets elected.

Bdale

Re: A question for all candidates

[Martin Michlmayr]

* Rune B. Broberg <[EMAIL PROTECTED]> [2003-02-26 14:27]:
> Only one person can 'win' this election, meaning we'll have 3
> candidates remaining after this election. How will not getting
> elected affect your work within Debian, and the goals you stated in
> your platforms?

As I said in my platform, I think there are many tasks one can do
without being DPL or being in any other recognized position.  However,
I also want to stress that being DPL would allow me to do the things I
plan to do more effectively.  Also, it would show me that the project
actually thinks that the tasks I listed in my platform are important,
and that the project stands behind what I'm doing.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: A question for all candidates

[Marcelo E. Magallon]

On Sat, Mar 08, 2003 at 05:02:09PM +1100, Martin Michlmayr wrote:

 > Also, it would show me that the project actually thinks that the
 > tasks I listed in my platform are important, and that the project
 > stands behind what I'm doing.

 I must have missed the memo.  Since when does this project work like
 that?  Last time I checked, the way we do a lot of the things you
 mention in your platform was by rolling up your sleeves and start
 working.  If "the project actually thinks that the task [you are doing]
 are important" people join you in your effort.  For example:

 * "First, I think there are several problems with the sponsorship
   system.  There is no listing of sponsored people and hence it is
   quite hard to keep track of them."

   Obviously good and obviously backed up by QA people.  No need
   whatsoever to be DPL to get this going.

 * "Second, I will re-introduce the New Maintainer postings."

   Obviously backed up by several people.  More than once people have
   asked what happened with this.  No need to DPL status either.  Only a
   good working relationship with the NM admin people is needed.  If DPL
   status is required for that, we might as well pack our stuff and go
   home.

 * "Third, I intend to put more focus on inactive developers."

   I'm starting to sound like a broken record.  Again, certainly backed
   up by QA people.

 * "The web site is too impersonal" (bug#76187)

   Why would anyone need to run for DPL to get such a thing done?  This
   is examplary of "roll up your sleeves and do it".

 As you put it yourself "as DPL, I will encourage similar efforts. You
 don't have to be DPL to get things done."  Exactly.  That's the way
 this project works.

 On the rest of the section entitled "internal functions" you resort to
 hand waving arguments revolving arround the idea of "face to face
 contact", which might or might not be a really good thing.  My personal
 impression from your platform is that you take that imagery of "the
 fearless leader" too seriously.  That kind of leader, the one that's
 cheered up by the masses when he makes personal appearences, is surely
 a good thing for fun (and therefore motivational) value, but that's
 rarely the kind of leader that gets to office by means of a vote.

 If I had to write an abstract for your platform, it would include the
 phrase "personal contact is the basis for good teamwork", since that's,
 after a couple of readings, the meat of your argument.

 In short, I'm still missing the answer to "what would make Michlmayr a
 better D*PL* than Bdale or Branden?"  (No, I didn't forget Moshe)

 Cheers,

-- 
Marcelo

Question for all candidates: Security team

[Henning Makholm]

It has been asserted on several occasions over the last few years that
the security team is overworked and understaffed. This is a problem
that is hard for the average developer to help with, because someone
who spontaneously volunteers for the job out of the blue shouldn't be
entrusted with secrets anyway.

Since the problem appears to be chronic, it must be that either the
developers who are being invited to do security work consistently
decline, or that the team does not even have the manpower to increase
their own manpower.

What do you as DPL candidates think that the DPL can do to help with
this situation?

-- 
Henning Makholm"You are in a little twisting
maze of passages, all different"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A question for all candidates

[Branden Robinson]

On Wed, Feb 26, 2003 at 02:27:16PM +0100, Rune B. Broberg wrote:
> Only one person can 'win' this election, meaning we'll have 3 candidates
> remaining after this election. How will not getting elected affect your
> work within Debian, and the goals you stated in your platforms?

I've largely limited the scope of my Platform this year to those things
which the DPL is uniquely or best empowered to accomplish.  Therefore,
if I am not elected, some of those things may go undone.

Whether I am elected or not, I will be continuing to work within the
Project as a package maintainer.  I am currently trying to groom some
co-maintainers for XFree86, for example.  :)

-- 
G. Branden Robinson|   Psychology is really biology.
Debian GNU/Linux   |   Biology is really chemistry.
[EMAIL PROTECTED] |   Chemistry is really physics.
http://people.debian.org/~branden/ |   Physics is really math.


pgp0.pgp
Description: PGP signature

Re: A question for all candidates

[Bdale Garbee]

[EMAIL PROTECTED] (Rune B. Broberg) writes:

> Only one person can 'win' this election, meaning we'll have 3 candidates
> remaining after this election. How will not getting elected affect your
> work within Debian, and the goals you stated in your platforms?

I will continue to work for Debian regardless of how this election turns out.

Since none of the other candidates presents a vision for how Debian should
grow and evolve that conflicts with the ideas I presented, I hope these
ideas will be carried forward by the project no matter who gets elected.

Bdale


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A question for all candidates

[Martin Michlmayr]

* Rune B. Broberg <[EMAIL PROTECTED]> [2003-02-26 14:27]:
> Only one person can 'win' this election, meaning we'll have 3
> candidates remaining after this election. How will not getting
> elected affect your work within Debian, and the goals you stated in
> your platforms?

As I said in my platform, I think there are many tasks one can do
without being DPL or being in any other recognized position.  However,
I also want to stress that being DPL would allow me to do the things I
plan to do more effectively.  Also, it would show me that the project
actually thinks that the tasks I listed in my platform are important,
and that the project stands behind what I'm doing.

-- 
Martin Michlmayr
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A question for all candidates

[Marcelo E. Magallon]

On Sat, Mar 08, 2003 at 05:02:09PM +1100, Martin Michlmayr wrote:

 > Also, it would show me that the project actually thinks that the
 > tasks I listed in my platform are important, and that the project
 > stands behind what I'm doing.

 I must have missed the memo.  Since when does this project work like
 that?  Last time I checked, the way we do a lot of the things you
 mention in your platform was by rolling up your sleeves and start
 working.  If "the project actually thinks that the task [you are doing]
 are important" people join you in your effort.  For example:

 * "First, I think there are several problems with the sponsorship
   system.  There is no listing of sponsored people and hence it is
   quite hard to keep track of them."

   Obviously good and obviously backed up by QA people.  No need
   whatsoever to be DPL to get this going.

 * "Second, I will re-introduce the New Maintainer postings."

   Obviously backed up by several people.  More than once people have
   asked what happened with this.  No need to DPL status either.  Only a
   good working relationship with the NM admin people is needed.  If DPL
   status is required for that, we might as well pack our stuff and go
   home.

 * "Third, I intend to put more focus on inactive developers."

   I'm starting to sound like a broken record.  Again, certainly backed
   up by QA people.

 * "The web site is too impersonal" (bug#76187)

   Why would anyone need to run for DPL to get such a thing done?  This
   is examplary of "roll up your sleeves and do it".

 As you put it yourself "as DPL, I will encourage similar efforts. You
 don't have to be DPL to get things done."  Exactly.  That's the way
 this project works.

 On the rest of the section entitled "internal functions" you resort to
 hand waving arguments revolving arround the idea of "face to face
 contact", which might or might not be a really good thing.  My personal
 impression from your platform is that you take that imagery of "the
 fearless leader" too seriously.  That kind of leader, the one that's
 cheered up by the masses when he makes personal appearences, is surely
 a good thing for fun (and therefore motivational) value, but that's
 rarely the kind of leader that gets to office by means of a vote.

 If I had to write an abstract for your platform, it would include the
 phrase "personal contact is the basis for good teamwork", since that's,
 after a couple of readings, the meat of your argument.

 In short, I'm still missing the answer to "what would make Michlmayr a
 better D*PL* than Bdale or Branden?"  (No, I didn't forget Moshe)

 Cheers,

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Question for all candidates: pushing people

[Andreas Schuldei]

* Wouter Verhelst ([EMAIL PROTECTED]) [070316 14:35]:
> > How would other candidates avoid dropping topics like this?
> 
> The only way you can do that is by actively asking people to produce a
> report when they said they'd do so.

that sounds to me like you wanted to continue with "but you cant
do thatas they are all volunteers and you cant push them" or so.
could you elaborate? were you in the position to push people to
do something in debian, and how did you do it? how was your
success rate? 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question for all candidates: Release process

[Lucas Nussbaum]

On 14/03/10 at 14:44 -0700, Russ Allbery wrote:
> This is for all candidates.
> 
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.  There's usually always at
> least some frustration, anger, and upsetness, and there seems to usually
> be at least one resignation over the course of a release, often in a way
> that hurts other activities in Debian for a time.
> 
> Do you have any ideas how, as DPL, you would (or even could) address this?
> I'm personally the most concerned with the social issues.  A delayed
> release can be frustrating but doesn't have that much negative impact, but
> volunteers with enough knowledge of Debian to be able to serve as release
> managers or helpers are rare.  And usually the arguments not only hurt
> their contributions to Debian but usually hurt the contributions to Debian
> of the people on the other side of the argument as well, who are often
> also valuable and difficult-to-replace volunteers.
> 
> Do you have any thoughts about how to resolve release issues with less
> hurt and negative impact to the project all around?

Three more release-related questions.

During the last debconf, the freeze of squeeze was first announced to
take place in December, then this decision was cancelled, and now we are
in March.
- How do you analyze what happened during last summer? What went wrong?
- What is your opinion on the motivations for the proposal to freeze in
  December? Specifically, in the future, should we try to coordinate our
  release process with Ubuntu's?
- So, we are now in March. What is your opinion with the release process
  so far? When do you see the release happening?

(I'm fully aware that the DPL is not in a position to take many actions
regarding the release. However, similar questions are likely to be asked
during post-election interviews, so we would better know how you will
answer ;)
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100315070919.ga26...@xanadu.blop.info

Re: Question for all candidates: Release process

[Margarita Manterola]

On Sun, Mar 14, 2010 at 6:44 PM, Russ Allbery  wrote:

> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.  There's usually always at
> least some frustration, anger, and upsetness, and there seems to usually
> be at least one resignation over the course of a release, often in a way
> that hurts other activities in Debian for a time.

I think that most of the frustration comes from the fact that the
release team is lacking manpower.  The job of the release team is very
stressful and very rarely do the RM and RA feel that their work is
appreciated.

> Do you have any ideas how, as DPL, you would (or even could) address this?

I've been thinking about this, due to the recent events, and I'm not
sure I have a solution.  As I've already commented, I'd like to set up
some projects that encourage more external (and internal as well)
contributors both to report and fix more bugs.  However, there's much
more to the release work than fixing RC bugs: managing transitions is
a LOT of work, that requires extra knowledge, and only DDs can do it.

We know from past experiences that throwing money at the problem would
only bring more trouble, so that's out of the picture.

So, the only way I see to help is documenting the work needed and
asking for help.  Maybe if more DDs knew the work needed to get their
own packages into testing, they would be able to help there, and
reduce the pressure on the Release Team.

> I'm personally the most concerned with the social issues.  A delayed
> release can be frustrating but doesn't have that much negative impact, but
> volunteers with enough knowledge of Debian to be able to serve as release
> managers or helpers are rare.  And usually the arguments not only hurt
> their contributions to Debian but usually hurt the contributions to Debian
> of the people on the other side of the argument as well, who are often
> also valuable and difficult-to-replace volunteers.

I agree with all of this, and I'm very much concerned about this
myself.  However, I don't see an easy way to fix this.  My ideas are
on how to make it easier to help out, but people won't necessary want
to help, and I can't think of a way to magically make people want to
help.

-- 
Besos,
Marga


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150642h6d3f431ejb3b1bd852f5b4...@mail.gmail.com

Re: Question for all candidates: Release process

[Margarita Manterola]

On Mon, Mar 15, 2010 at 4:09 AM, Lucas Nussbaum
 wrote:

> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?

What went wrong: a decision was taken without consulting the affected teams.

This is a situation that has happened over and over again in Debian.
The Debian community does not take it well when they are informed of a
decision already taken without having a say on it. We should learn
from this to never make this mistake again: always keep involved
participants in the loop and consult with other people before
announcing something as a taken decision.

What went right: after the many messages stating that the December
freeze was NOT a good idea, specially after Mark Shuttleworth
clarified what he meant by "freeze" (stating which versions to include
in the release), the Release Team sent a mail saying that freezing in
December was not a good idea and that the freeze would most probably
happen on early 2010.

> - What is your opinion on the motivations for the proposal to freeze in
>  December? Specifically, in the future, should we try to coordinate our
>  release process with Ubuntu's?

I think it's generally a good idea, *BUT* I think we should freeze
about the time when Ubuntu releases the LTS, *NOT* 4 or 5 months
before.  Because, as we all know, Ubuntu doesn't really freeze until
really close to the release. So, freezing before that is the same as
not coordinating at all.  This would mean that Ubuntu would release
the LTS in April and Debian would release maybe in July or August. I'm
perfectly ok with that.

I also think that releasing roughly every two years, with a
kernel/X/etc upgrade in the middle (like was done with etchnhalf), is
good. I value stability far more than "bleeding edge", and I know that
releasing more often than that is going to have quite an impact in
stability.  Where I work, most users (about 150) are still using Etch,
because they are used to it and have no real need of anything newer.

All in all, this is my opinion as just a DD.  The release process is
the work of the Release Team, and it's their call in the end.
However, to avoid the turmoil caused last year after the DebConf
keynote / press release, the RT should always keep involved teams in
the loop when setting a release (or freeze) date.

> - So, we are now in March. What is your opinion with the release process
>  so far? When do you see the release happening?

I'm very saddened by Luk's resignation from yesterday, I think it's
mainly the result of having to do too much work by too few people.
This leads to stress and frustration, and those tend to lead to
resignations.  Now we have to give the team some time to re-arrange
themselves and find a way to continue.

I won't make any predictions, since they'd make very little sense in
the current context.  I do plan to help the Release Team releasing
squeeze, in whatever my capacity, and I'm hoping that it'll happen
this year, so that the whole LTS syncing thing can happen.  However,
if in order to have a stable, robust and clean release we ended up
releasing in 2011, I'd still consider it a good trade off, and I'd
still back up the Release Team.

-- 
Besos,
Marga


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150814w52c2ee60h9ab8050311128...@mail.gmail.com

Re: Question for all candidates: Release process

[Frans Pop]

Margarita Manterola wrote:
> I think that most of the frustration comes from the fact that the
> release team is lacking manpower.  The job of the release team is very
> stressful and very rarely do the RM and RA feel that their work is
> appreciated.

I disagree. I think the main problem is that there are two main sides to 
what the Release Team does and that the cause of the frustration on the 
side of the rest of the project is that one of those is sides has been 
neglected. And that frustration in the rest of the project creates the 
negative feedback and criticism which in turn creates the stress in the 
RT.

The two sides I'm talking about are:

- the technical work around preparing a release
  This includes managing transitions, migrations; doing removals;
  maintaining tools; etc.

This seems to be what the RT has been focussing on after Sarge. This is 
also where most manpower currently goes. And it's very necessary and 
important. And in general I think it's done quite well (except when 
someone decides - without any prior announcement or opportunity for review 
or comment - to do a mass removal of packages from testing because they 
have a random RC bug open even though the importance of the package 
massively outweighs the practical impact of the bug).

- the actual *management* of the release process
  This involves planning and coordinating the work that needs to be done
  by "regular" DDs; ensuring that not only the archive is in a releasable
  state, but that also the website and documentation (including
  translations) have been updated; stimulating BSPs; preparing release
  announcements (and giving people who's work your announcing time to
  review and comment what you've written for them); informing everybody
  involved of the status and progress of a release.
  And also tracking the status of architectures and *discussing* with the
  project what to do when an arch has problems (instead of just deciding
  on things in isolation); keeping track of release goals and stimulating
  work on them so that they are actually implemented, 

The quality of a Debian release is determined by much more than just the RC 
bug count. And it all needs to be managed, or at least coordinated. And 
*everything* needs to be ready on the day, not just one aspect.


During the Sarge release these two sides were in balance. After that, for 
Sarge stable releases and the Lenny release, the second side was horrible. 
And several people contributing a lot of work in strongly release-related 
areas have been driven away by that.
After Lenny things have improved in some areas (communication about ports 
has been quite good for example and so has the management of the last 
couple of stable point releases), but for Squeeze we've only seen a very 
few rather general status mails, but no coordination at all.

The Release Team should IMO keep in mind that it's not *they* who make a 
release, but the whole project together. And the best way to get respect 
for their work is for them to respect the vastly bigger amount of work 
done by all other DDs collectively.

The fact that they control the switches does not mean that they can 
unilaterally make any decision regarding the work of others. There is no 
problem with the RT making the *final* decision about release related 
issues, but they simply cannot make most decisions without checking with 
the rest of the project. If only simply because in most cases they won't 
have all relevant information.
And checking with the rest of the project is *not* asking a few buddies on 
a selected channel on IRC. It's doing proper announcement and RFC/RFRs on 
the mailing lists intended for that purpose.


And finally, the best way to get help is to be open about what you're 
doing. If you hide yourself away and don't communicate with the project 
you don't get help. I think the very noticeable change in the FTP team is 
proof of that.

IMO for a lot of the above the primary responsability lies with the person 
with the title/role of Release Manager. Ideally the Release Manager should 
spend more time on communicating with the rest of the project than on 
handling transitions.

The challenge for an RM when the team can't handle the workload is not to 
do it all himself, but to continue communicating and get help.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003151630.25818.elen...@planet.nl

Re: Question for all candidates: Release process

[Margarita Manterola]

Hi Frans,

Let me first start by stating that I'm sadly concerned about the tone
of your mail.

Nobody claims that the release process has been done perfectly, there
have been mistakes, but we are all human and we can all make mistakes.
 It's alright to point those mistakes out so that people can correct
them, but I find your mail disturbing, because it feels more like
attacking the past Release Managers than trying to improve the overall
project quality.

With that in mind, I'll answer only a few of the issues you raise,
those that I feel are relevant to the upcoming election.

On Mon, Mar 15, 2010 at 12:30 PM, Frans Pop  wrote:

> The Release Team should IMO keep in mind that it's not *they* who make a
> release, but the whole project together. And the best way to get respect
> for their work is for them to respect the vastly bigger amount of work
> done by all other DDs collectively.

I think that the whole project should keep that in mind, not just the
Release Team, and I feel there are many people who don't care enough
about releases and thus do not help out.

I agree that communicating more often could help, but it would also be
necessary to agree on some common goals for the project, so that we
really are working all together as a community instead of just doing
some solo work. That's one of the things I plan to do as DPL:
establish (by talking with the affected teams) some common goals to
work on, and communicate them project wide so that we are all working
together towards that.

> Ideally the Release Manager should
> spend more time on communicating with the rest of the project than on
> handling transitions.

I agree with this (and many of the removed-due-to-being-aggressive
quotes).  However, the lack of man power means that the Release
Managers end up in charge of transitions and lack the time to do the
real communication and coordination.

The role of the DPL is to help developers do their work as good as
possible.  In this case, the only thing that can be done is try to
inspire more people to help out with the release team, but this is not
an easy task, since working on transitions requires extra knowledge
that many DDs don't have, and the release team members don't
necessarily have the time to train them.

We currently and very sadly don't have a Release Manager.  Please let
me suggest that, when a Release Manager is appointed, you should
direct your suggestions about management to them, focusing on what
could be done better, without the need to attack whatever was done
wrong in the past.

-- 
Besos,
Marga


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150916o58d9f400x88b4dbe793a7a...@mail.gmail.com

Re: Question for all candidates: Release process

[Stefano Zacchiroli]

On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.

To some extent, I believe it is normal. Releases are our main
"products", they define our purpose. The people which are putting their
names in driving the release process, i.e. the members of the release
team, are very tightly bound to the release process. The closer we get
to a release, the closer they might feel pressure, which sometimes has
unfortunate consequences.

My impression is that most impromptu resignations in Debian happen as a
consequence of some form of burn-out, which are unfortunately not
uncommon in volunteer FOSS projects. I don't believe the release team
constitutes an exception to this unfortunate rule.

A general cure to this is to avoid people taking over their shoulders
more responsibility than they can handle. I was very positively
impressed when Steve McIntyre's team review of two years ago found out
people involved in an incredibly high number of Debian teams and
actually incouraged those people to step back from some of them. We
should encourage DDs to periodically review their involvements and focus
their energies on a few specific areas. Being a member of the release
team, or even the release manager is, again, no special case.  As it is
hard to actively state "I step back", we should also more frequently do
(self-)appointments with an attached "expiry date", when the date
expires the involved people can "snooze" it actively or just let others
know that it is time for them to move on to Debian activities which are
more fun for them.

> Do you have any thoughts about how to resolve release issues with less
> hurt and negative impact to the project all around?

On one hand, I believe that the pressure on, and even some personal
conflicts with, the release team could have been much lower in the past
(generally, not necessarily only in this last release process) with a
bit more communication with project. As a DPL, I would generally prod
the release team for periodic status reports (at least monthly) which
are much needed, considering the peculiar role of the release process in
Debian. If prodding is not enough, the DPL can also take care of the
communication him/herself.

On the other hand, I think the release team has felt in the past more
than a bit of frustration, due to the apparent disinterest of DDs in
getting a release done. I particularly remember during DebConf8 (Lenny
release cycle) a deserted BSP which was largely perceived as lack of
interest in getting the RC bugs count down. That is just an example and
maybe not even the most appropriate one [1], but the problem exists:
beside maintainers that don't care about fixing RC bugs in their
packages, not so many people care about helping in releasing Debian, by
working on packages other than theirs. That can easily make the release
team feel "alone against the release", which is surely not a productive
context to work in.

Ultimately, I believe this is a cultural problem that will take us quite
some time to fix. I'm aware of various initiatives in the right
direction:

- use the NM process to coach newbies about the importance of fixing
  packages other than theirs (we already request to provide RC bug
  patches during T&S). I personally had very good responses on this from
  a couple of NMs which started patching and/or NMU-ing RC-buggy
  packages with (proper) patches just after becoming DDs

- more generally, diminish strong package ownership by communicating
  that contributions like NMUs are good, as long as they are done
  following the rules (initiatives like RCBW and its predecessors
  attracted quite a lot of "minions", for instance)

The ideal bottom line of this is that, if the DD body starts feeling
more part of the release process (rather than only thinking at their own
pet packages), then DDs will more and more stand on the side of the
release team, rather than against it.

Cheers.

[1] one can argue that a DebConf should better be used in other ways, etc

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Wouter Verhelst]

On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> This is for all candidates.
> 
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.  There's usually always at
> least some frustration, anger, and upsetness, and there seems to usually
> be at least one resignation over the course of a release, often in a way
> that hurts other activities in Debian for a time.

I believe social issues are the main problems Debian is still facing at
this time, not just in the release process.

> Do you have any ideas how, as DPL, you would (or even could) address this?
> I'm personally the most concerned with the social issues.

The social issues in our community are self-enforcing. That is, if it is
accepted that people are rude, then there is nothing you can really do
about repetitive rudeness towards your person, beyond resigning.
However, if we, as a project, decide that no, rudeness and ad-hominem
attacks are not acceptable, then such things will not go unnoticed.

As a DPL, I will promote, in whatever way I can, to publicly (but
politely) disapprove of what should be unacceptable behaviour; but also
to allow people to make mistakes.

> A delayed release can be frustrating but doesn't have that much
> negative impact, but volunteers with enough knowledge of Debian to be
> able to serve as release managers or helpers are rare.  And usually
> the arguments not only hurt their contributions to Debian but usually
> hurt the contributions to Debian of the people on the other side of
> the argument as well, who are often also valuable and
> difficult-to-replace volunteers.

Indeed. I use a different wording, but basically outline the same thing
in my platform, and I believe it is the single most important problem
Debian is facing currently. Finding volunteers is hard; keeping them is
even harder. If we do not have a welcoming community, then we drive
people away, and we should not do that.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Wouter Verhelst]

On Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum wrote:
> On 14/03/10 at 14:44 -0700, Russ Allbery wrote:
> > This is for all candidates.
> > 
> > Releasing is regularly the hardest thing that Debian does, not just
> > technically but also socially.  Apart from the standard issues of setting
> > deadlines, RC bug counts being high, and similar difficult technical
> > issues, the process seems to eat volunteers.  There's usually always at
> > least some frustration, anger, and upsetness, and there seems to usually
> > be at least one resignation over the course of a release, often in a way
> > that hurts other activities in Debian for a time.
> > 
> > Do you have any ideas how, as DPL, you would (or even could) address this?
> > I'm personally the most concerned with the social issues.  A delayed
> > release can be frustrating but doesn't have that much negative impact, but
> > volunteers with enough knowledge of Debian to be able to serve as release
> > managers or helpers are rare.  And usually the arguments not only hurt
> > their contributions to Debian but usually hurt the contributions to Debian
> > of the people on the other side of the argument as well, who are often
> > also valuable and difficult-to-replace volunteers.
> > 
> > Do you have any thoughts about how to resolve release issues with less
> > hurt and negative impact to the project all around?
> 
> Three more release-related questions.
> 
> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?

From my perspective, it looks like some people jumped the gun a little,
though with the best of intentions.

> - What is your opinion on the motivations for the proposal to freeze in
>   December? Specifically, in the future, should we try to coordinate our
>   release process with Ubuntu's?

I don't think it hurts anyone for Debian to cooperate with another
project, be that project Ubuntu, the FSF, or something else.

If the cooperation with Ubuntu worked well for this release (I am not
very up-to-date on the details here), then I see no reason why we should
not do so.

> - So, we are now in March. What is your opinion with the release process
>   so far? When do you see the release happening?

In my opinion, the best release we ever had (that I was a part of, at
least) was the Etch release process; shortly after Sarge had been
released, the release managers had started to regularly update the
project as a whole on where we were in the process, and I believe that
worked very very well. During the whole of the Etch release process,
there was never really a point in time where I felt I didn't know how
far away the release still was.

It feels to me as though the frequency and/or quality of updates has
reduced somewhat since the Etch release, though I'll readily admit that
that is just a gut feeling. At any rate, I do not feel I am as
up-to-date as I was during the Etch release process on when the release
is going to happen. I don't think it's going to take more than, say,
half a year, though.

> (I'm fully aware that the DPL is not in a position to take many actions
> regarding the release. However, similar questions are likely to be asked
> during post-election interviews, so we would better know how you will
> answer ;)

Hope that answers that,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Frans Pop]

Reading Wouter's post in this thread just now I realize I made a fairly 
stupid mistake when writing my mail.

Frans Pop wrote:
> This seems to be what the RT has been focussing on after Sarge. [...]

s/Sarge/Etch/

> During the Sarge release these two sides were in balance. After that, for
> Sarge stable releases and the Lenny release, [...]

s/Sarge/Etch/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003160723.26265.elen...@planet.nl

Re: Question for all candidates: Release process

[Charles Plessy]

Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit :
> 
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.

Dear Russ and everybody,

I think that our release process is manpower-hungry by design, and that the
more packages and architectures we have, the harder the release is. I propose
to refocus our efforts.

Solving a thousand of RC bugs is a herculean task for a small group of persons.
But why should they do that in the first place? Most of these bugs are the
responsibility of the package maintainers. If they can not make their package
ready for the release, will they be able to help for stable support? Who will
do that work?

I propose that we reshape the sections and priorities of our archive, so that
it is easy to remove from Testing any RC bug that is not in a core pakcage,
and is old and not tagged RFH. In parallel, I propose that the definition
of what the ‘core’ is can vary between architectures.

The goal is not only to reduce the workload of the release team and the
porters. It is also to give some meaning to the presence of a package in a
stable release. These packages must be there because there is agreement that
enough users are insterested in it, and are comfortable with the idea to keep it
at the same version for a long time.

For many peripheral leafs and branches of our dependancy tree, let's innovate
and distribute them through other channels, like official backports and even
the new snapshot system that is being set up. When all of this is aptable from
the official Debian mirrors, it will open great opportunities to build tailored
Debian systems, for instance with the ‘blends’ framework.


Debian is volunteer-driven, so the release can only happen by coordination.
Acutally, it is a coordination process by nature: a release is a moment in the
development where all the core components work well together. If these
components evolve independantly, it will hardly happen by chance. Motivation
must be there on both ends. This is why I propose to limit the release to
the packages where there is a real motivation for it. When maintainers feel the
need for a release, they will have to talk to the others and eventually make
concessions on their timeline. Not to mention that for many of our packages,
there is actualy nobody who regularly cares for them anymore. In that sense, I
think that membership issues are one of the roots of our difficulties to
release.

As a DPL I will help the Project to evolve its release and membership process
through my constitutional roles: leadership in discussions, GRs, and
delegations. I expect as a result that the release work will become much more
social than technical, with all participants doing their part of the
housekeeping work.

Have a nice day,


-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317005207.ga6...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Gunnar Wolf]

Wouter Verhelst dijo [Tue, Mar 16, 2010 at 12:57:13AM +0100]:
> In my opinion, the best release we ever had (that I was a part of, at
> least) was the Etch release process; shortly after Sarge had been
> released, the release managers had started to regularly update the
> project as a whole on where we were in the process, and I believe that
> worked very very well. During the whole of the Etch release process,
> there was never really a point in time where I felt I didn't know how
> far away the release still was.
> 
> It feels to me as though the frequency and/or quality of updates has
> reduced somewhat since the Etch release, though I'll readily admit that
> that is just a gut feeling. At any rate, I do not feel I am as
> up-to-date as I was during the Etch release process on when the release
> is going to happen. I don't think it's going to take more than, say,
> half a year, though.

Hmm, you got me thinking here on why this happened, as I share your
impression. Maybe it was because the project as a whole put more care
into the release process after the massive pain it was to release
Sarge, a three-year-long pain we didn't want to suffer again? For
Lenny we lost some of that push, although the release process was
still mostly swift, with a minor slip regarding what we expected. 

As for the reasons why we are not freezing yet... I think it is
somewhat a lack of commitment to what the Release Team says, as (too)
many people felt betrayed with the way the freeze-related
announcements were made (a topic that has already been analized
here).

So, going back to the questioning of the candidates: Do you agree with
this very simplistic analysis? If so, how would you push to get the
drive and the confidence back?

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317035655.gb13...@gwolf.org

Re: Question for all candidates: Release process

[Bernhard R. Link]

* Charles Plessy  [100317 01:52]:
> I propose that we reshape the sections and priorities of our archive, so that
> it is easy to remove from Testing any RC bug that is not in a core pakcage,
> and is old and not tagged RFH.

How is that different from the current procedure?

> In parallel, I propose that the definition
> of what the ‘core’ is can vary between architectures.

And do you think that will make it easier or harder to do a release?

> The goal is not only to reduce the workload of the release team and the
> porters. It is also to give some meaning to the presence of a package in a
> stable release. These packages must be there because there is agreement that
> enough users are insterested in it, and are comfortable with the idea to keep 
> it
> at the same version for a long time.

So you think we currently put things in which we do not want to keep the
whole time?

> For many peripheral leafs and branches of our dependancy tree, let's innovate
> and distribute them through other channels, like official backports and even
> the new snapshot system that is being set up.

Welcome to the first circle of rpm hell...

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100317101519.ga31...@pcpool00.mathematik.uni-freiburg.de

Re: Question for all candidates: Release process

[Wouter Verhelst]

On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Tue, Mar 16, 2010 at 12:57:13AM +0100]:
> > In my opinion, the best release we ever had (that I was a part of, at
> > least) was the Etch release process; shortly after Sarge had been
> > released, the release managers had started to regularly update the
> > project as a whole on where we were in the process, and I believe that
> > worked very very well. During the whole of the Etch release process,
> > there was never really a point in time where I felt I didn't know how
> > far away the release still was.
> > 
> > It feels to me as though the frequency and/or quality of updates has
> > reduced somewhat since the Etch release, though I'll readily admit that
> > that is just a gut feeling. At any rate, I do not feel I am as
> > up-to-date as I was during the Etch release process on when the release
> > is going to happen. I don't think it's going to take more than, say,
> > half a year, though.
> 
> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long pain we didn't want to suffer again? For
> Lenny we lost some of that push, although the release process was
> still mostly swift, with a minor slip regarding what we expected. 

This is quite possibly correct.

> As for the reasons why we are not freezing yet... I think it is
> somewhat a lack of commitment to what the Release Team says, as (too)
> many people felt betrayed with the way the freeze-related
> announcements were made (a topic that has already been analized
> here).

I don't sense it that way. There was initially a bit of disappointment
among many people, indeed, but with the change of plans that was made
fairly quickly, I think the trust was restored.

> So, going back to the questioning of the candidates: Do you agree with
> this very simplistic analysis? If so, how would you push to get the
> drive and the confidence back?

To get the drive back is something that the release team needs to do. I
can work with them on that, if necessary, but I can't do it for them.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Stefano Zacchiroli]

On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long pain we didn't want to suffer again? For
> Lenny we lost some of that push, although the release process was
> still mostly swift, with a minor slip regarding what we expected. 

I do think this kind of analysis is a bit too simplistic to explain what
has happened. Our release cycles are long enough to encompass *a lot* of
factors that can impact on how "good" a release cycle is perceived to be
by DDs. For sure all of us experienced the pain of getting Sarge out,
but I don't believe that, as a consequence, our collective conscience
has risen up and got a better Etch release cycle.

FWIW, I haven't personally felt the Lenny release cycle to be worse than
the Etch one, both felt quite slick to my DD eyes.

> As for the reasons why we are not freezing yet... I think it is
> somewhat a lack of commitment to what the Release Team says, as (too)
> many people felt betrayed with the way the freeze-related
> announcements were made (a topic that has already been analized here).

I don't think the residual effects of the past-DebConf-flames had much
(cascade) effect on why we are not freezing yet.  All in all the usual
reasons for not freezing are a too high RC bug count [1] and some
important work still to be completed (e.g. big transitions). If we are
not freezing yet, it is most likely do to those classical reasons, no
need to piggyback others, IMO.

> So, going back to the questioning of the candidates: Do you agree with
> this very simplistic analysis? If so, how would you push to get the
> drive and the confidence back?

Essentially, I believe I disagree with the analysis :-)

Ultimately, driving the release process is the specific role of the
release team, on which the DPL should not intervene directly. The help
that the DPL should contribute to the release team is of a different
nature: helping in staffing the team if/when needed, ensure that the
release team communicates periodically about the release status (by
prodding the team and/or helping them to send out status bits),
motivating developers to feel part of the release process.  The above
items are not specific of any release cycle, it is just what I think it
should be a sane relationship between the DPL, the release team, and the
DD body.


Cheers.


[1] I've discussed in another thread how I think we need a cultural
shift on that, making it more distribute within the project. Of
course this is nothing specific to the current release cycle, but it
gets more and more important as our distro grows

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Margarita Manterola]

On Wed, Mar 17, 2010 at 12:56 AM, Gunnar Wolf  wrote:

> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long pain we didn't want to suffer again? For
> Lenny we lost some of that push, although the release process was
> still mostly swift, with a minor slip regarding what we expected.

As has been said by others, I don't think this is accurate.  It might
have been one of the reasons, but there are probably many others.  For
example, the competition of dunk-tank vs dunc-bank, made Etch one of
the best Debian releases because it REALLY had very very few bugs.  In
other releases, there might have been no RC bugs reported, but the
bugs were there anyway.

Another thing that I see "special" about Etch, is that Steve and
Andreas stayed as managers after Sarge was released, so they came to
Etch with a lot of knowledge on their shoulders.  After that, it has
been sadly very hard for us to keep the RMs for long enough.

And there are probably a lot of other factors to take into account of
Etch's success.

> As for the reasons why we are not freezing yet... I think it is
> somewhat a lack of commitment to what the Release Team says, as (too)
> many people felt betrayed with the way the freeze-related
> announcements were made (a topic that has already been analized
> here).

I don't agree here.  I think that the lack of commitment to the
release is more probably due to lack of enough communication from the
Release Team and lack of motivation from the general developer body.
This is not intended as criticism towards what the RT has done, but
it's more of a diagnose: we are lacking motivation and more
communication of near-future goals could help us work better as a
group.

Personally, even though I was shocked in July by the unexpected
announcement, I was very glad to see the Release Team find a
compromise solution, that fit the project's time better, and thus in
no way do I feel "betrayed".  I don't think the majority of developers
does.

I think that the lack of manpower is a much bigger factor.  As has
been said, here and elsewhere, we are lacking people on this area as
much as on many other areas in Debian, and that shows.

> So, going back to the questioning of the candidates: Do you agree with
> this very simplistic analysis? If so, how would you push to get the
> drive and the confidence back?

As said, I don't agree.

What I plan to do as DPL that would help in this area, is set some
project-wide goals, so that developers can be inspired to focus their
energies on those goals, and also several initiatives to get more
people to help Debian, both by reporting and by fixing bugs.

-- 
Besos,
Marga


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003171822k5f26d409ma77ed9c07e962...@mail.gmail.com

Re: Question for all candidates: Release process

[Charles Plessy]

Le Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum a écrit :
> 
> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?
> - What is your opinion on the motivations for the proposal to freeze in
>   December? Specifically, in the future, should we try to coordinate our
>   release process with Ubuntu's?
> - So, we are now in March. What is your opinion with the release process
>   so far? When do you see the release happening?

Hi Lucas,

I was really disapointed when I read the press release. After announcing a
decision to the public, it is very difficult to change it; it really gave me
the impression to have my arm twisted. The freeze of Lenny was quite long, and
I tried to play the game, not updating my packages but doing release-oriented
work (including some tasks very specific to Debian Med, which did not have an
impact on Lenny's releasability). As a consequence, I was very worried that I
would not be able to update my packages to all the new upstream releases that
happened during the freeze, if we would freeze again in December.

This said, I am well aware that all my packages are not essential to Debian's
life, and I decided to not complain too much and trust the judgement of the
release team.  However, my personal opinion was that it is not a good idea to
release Debian with packages less up to date and a shorter security support
than Ubuntu. I would rather release on the years where there is no Ubuntu LTS.
This way, people trained to use dpkg-based distributions have the opportunity
to install a recent release with a reasonably long support each year, instead
of each second year. I think that this would maximise Debian and Ubuntu's
user base.

In this elections I propose to change our release philosophy. Depending how
oftern the kernel, libc, GNU, GCC, X.org, and other bright software stars align
in the sky, it could mean that we could release a core distribution more often
(than each second year) if we were interested in committing to this effort.
Still, a synchronisation with Ubuntu is taking the problem in the wrong
direction, I think. I do not have a long experience in collaborations with
Ubuntu but it seems that to meet deadlines, they do not hesitate to diverge
with upstream projects much more than what we are used to. I do not think that
we shall follow them in this path. I see more collaborations made on
opportunity basis, when both distribution's choices are naturally converging.
We can not promise to be ready to release the 1st of April 2012.

Now we are in March and I do not know when we will release. For the Lenny
release, with the release goals, the progressive freeze and information emails
from the release team, we went through milesones that I think helped a lot the
Project have a good feeling of the timing. The last footstep took more time.
It was written often that it is because there were too many RC bugs, but I
think that the true reason is that we were waiting for the installer team. I do
not write this to throw a stone to them, but to repeat once again that fixing
abandonned package does not make the release closer [but if you have fun with
this, do not stop! Debian is also about having fun]. Turning the spotlights on
the most difficult blockers would be very helpful.

I do not know if we can release soon, in the sense that I do not know if the
packages providing the core functionalities of our operating system are ready.
Honestly, as a DD I am not interested to fix bugs like python packages that do
not work with version 2.6 if the maintainer does not at least ask for help (I
would rather be interested to participate to bolder package removal sessions).
If many other DDs share the same impression, and if all RC bugs are left in the
same bag without indication of priority, then we probably will not release
soon. Milestones like freezing the toolchain would send a strong message that
it is time to refocus our efforts from our own packages and team to the last
blockers.

Since the original plan was to release with Ubuntu LTS and that will not be
done, as a DPL I would ask the release team to update the project on its plans.
Have we lost the announced benefits of a joint release and postopone for more
than a couple of months to allow more developments, or are we very close to
freeze our core toolchains anyway ? Frans Pop wrote an insightful email on how
the release is also a lot of communication work. If I am elected DPL, I will
emphasise this role in the delegation given to the release managers.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100319012849.ga1...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Andreas Barth]

* Charles Plessy (ple...@debian.org) [100317 01:52]:
> I propose that we reshape the sections and priorities of our archive, so that
> it is easy to remove from Testing any RC bug that is not in a core pakcage,
> and is old and not tagged RFH.

We already do that, provided the RC bug is old enough. This (and other
parts of your answer) show clearly that you don't know how the current
release process works (and also didn't read our mails on
debian-devel-announce).

BTW, fixing of RC bugs is not done "by the release team", but
(thanksfully) by a large group of Debian Developers; of course also
members of the release team fix RC bugs :)



Andi


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100324091605.gr19...@mails.so.argh.org

Re: Question for all candidates: Release process

[Charles Plessy]

Hello Bernhard and everybody,

I think that the ‘RPM hell’ that you used to comment my propositions is more
related to a situation when independant distributions are using the same
package format, than when a distribution offers multiple repositories that obey
to a policy that keeps the whole system functional. We actually enter in the
era of the ‘DEB hell’ since the success of Ubuntu, with users asking support
for cross-distribution package installation. In the end, it is more a
communication problem than a technical problem. We should make it clearer that
it is not because the packages do not carry the distribution name that they are
not specific to a distribution. Perhaps a page about ‘our packaging system’ for
end-users on our website?

Regarding my proposal, that is internal to Debian, I do not think that it is
impossible. What I propose is a way for package maintainers to signal that
their package is peripheral in the Debian system, in an opt-in manner. Debian
is running out of manpower, and I think that it will be useful to let know that
a given package can be given a low priority for tasks. In my experience,
trivial RC bugs on not-so important packages attract volunteers because it is
very rewarding to close RC bugs. Also, I learnt a lot by participating to the
‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged
to challenge a bug that is far beyond our technical capacities, because help
like triaging and pinging the reporters is very useful and frees skilled hands
that are much more useful at other tasks. So in my opinion, not all RC bugs are
equal, and a better priority system would be useful to help volunteers to chose
their focus.

Our current priority system does not fit that task. Because of the rules about
conflicts, important packages like postfix are of priority extra. By
refactoring our priority system, we could make a much better usage of a
priority level that really means ‘extra’ in the sense of ‘do not bother if you
have more important things to do’.

With a priority system improved along this direction, I think it opens the
possibility to let some architectures release without the least important
packages. Once I reported upstream that his scientific software was not working
on Sparc. ‘I know‘, was the answer. This software, I want to bring it to the
scientific communauty, and like the upstream author, I know that no researcher
is seriously considering running it on Sparc for work.  Why not distributing it
only on amd64 until a user requests it on another architecture? Even on the
other platforms where it builds, I have no clue if it works. And in my
experience, the more regression tests I enable in my packages, the more I
realise that they do not work on the platforms that neither upstream nor the
users are using.

I am very tempted to go even further and would like to distribute some packages
for the stable distribution only through official backports for instance. Also,
in my field, while people usually want to have the latest version to start
with, they also do not want to change in the course of their analysis. I hope
that the future package snapshot system will help us to satisfy this need. In
conjunction with system image builders, Debian pure blends and ‘cloud
computing’, it will be very powerful.

Will it make the release easier? I think so, even if it is definitely not a
magical wand. It transfers some responsabilities, and the work load that comes
with, from the release team and the porters to the maintainers of leaf packages
of low priority. I would like the Debian project to trust more its maintainers,
and allow this transfer.

Have a nice week-end,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327061703.ga28...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Paul Wise]

On Sat, Mar 27, 2010 at 2:17 PM, Charles Plessy  wrote:

> Regarding my proposal, that is internal to Debian, I do not think that it is
> impossible. What I propose is a way for package maintainers to signal that
> their package is peripheral in the Debian system, in an opt-in manner. Debian
> is running out of manpower, and I think that it will be useful to let know 
> that
> a given package can be given a low priority for tasks. In my experience,
> trivial RC bugs on not-so important packages attract volunteers because it is
> very rewarding to close RC bugs. Also, I learnt a lot by participating to the
> ‘bug sprint’ organised by Josselin for Lenny, that we should not be 
> discouraged
> to challenge a bug that is far beyond our technical capacities, because help
> like triaging and pinging the reporters is very useful and frees skilled hands
> that are much more useful at other tasks. So in my opinion, not all RC bugs 
> are
> equal, and a better priority system would be useful to help volunteers to 
> chose
> their focus.

Does popcon not already provide a way to order packages based on
importance? rc-alert has both options for sorting bugs by both local &
global popcon score.

If not, what criteria would you suggest we use to prioritise RC bugs?
Should we change bts.turmzimmer.net to use that for ordering?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e13a36b31003270113p5ec3a20ew8570cbb19e23d...@mail.gmail.com

Re: Question for all candidates: Release process

[Stefano Zacchiroli]

On Sat, Mar 27, 2010 at 03:17:03PM +0900, Charles Plessy wrote:
> In my experience, trivial RC bugs on not-so important packages attract
> volunteers because it is very rewarding to close RC bugs.

> So in my opinion, not all RC bugs are equal, and a better priority
> system would be useful to help volunteers to chose their focus.

Absolutely: not all RC bugs are equal, there are easy and hard ones.
Letting aside truisms like "they should all be fixed anyhow", the
problem is that how much they are difficult to fix depends on who
approaches them (which might well be another truism), so you can't
really prioritize bugs, for release purposes, according to how difficult
they are.

> Also, in my field, while people usually want to have the latest
> version to start with, they also do not want to change in the course
> of their analysis. I hope that the future package snapshot system will
> help us to satisfy this need. In conjunction with system image
> builders, Debian pure blends and ‘cloud computing’, it will be very
> powerful.

I don't understand what "cloud computing" has to do with your idea of
using package priorities to release differently different sub-systems
within Debian. I'm well aware that we are currently lagging behind in
the race for OS for the cloud (and we should really catch up, at least
in terms of visibility), but what it has to do with your idea?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

[Charles Plessy]

Le Sat, Mar 27, 2010 at 04:13:11PM +0800, Paul Wise a écrit :
> 
> Does popcon not already provide a way to order packages based on
> importance? rc-alert has both options for sorting bugs by both local &
> global popcon score.

Hi Paul,

Popcon is definitely a potent indicator, but has its flaws as well. After all,
the median popcon score of Debian's ports is quite low, and we give them a lot
of importance. I think that adding priorities in the equations can be useful,
but after reorganising them, because for the moment, a very large majority of
RC-buggy packages are of priority ‘optional’, which does not tell much.

Of course, I am not campagning on that detail (the priorities), but more on the
fact that we can try other release strategies, and I think that refactoring the
priorities would open more possibilities. That is the main motivation for me to
give this example.


> Should we change bts.turmzimmer.net to use that for ordering?

That is really up to the bts.turmzimmer.net users. When I use it, i just go in
alphabetic order and evaluate priority myself… Bapase could a nice addition,
for people like me who are more on the removal mood.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327153759.ga31...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Bernhard R. Link]

* Charles Plessy  [100327 06:17]:
> I think that the ‘RPM hell’ that you used to comment my propositions is more
> related to a situation when independant distributions are using the same
> package format, than when a distribution offers multiple repositories that 
> obey
> to a policy that keeps the whole system functional.

Even repositories from the same project tend to diverge enough that
everything fails apart from a user perspective. One of the biggest
practical advantages of Debian is that there is one Release of
virtually everything. Everything fits and no incompatiblities of the
different 'unimportant' things (Remember what is unimportant for the
general is still important for most the people using it).

Thus splitting the archive in "core" and "non-core" can at worst create
multiple diverging no longer matching repositories for the different
tasks. And at best causes one core system freezing earlier and then all
the rest freezing based on that, which is something Debian already tried
without splitting things apart and I got the impression people did not
think that lead to anything but problems.

> Regarding my proposal, that is internal to Debian, I do not think that it is
> impossible. What I propose is a way for package maintainers to signal that
> their package is peripheral in the Debian system, in an opt-in manner. Debian
> is running out of manpower, and I think that it will be useful to let know 
> that
> a given package can be given a low priority for tasks.

We lack manpower in core tasks. In the packages that are "too big to
fail". People never had much problem to keep packages unimportant for
the general out of releases (even to the point of packages I miss desperately).

Some system to direct focus might be nice, but I really doubt it would
change things much. Anyone with a little bit of knowledge knows what the
core packages are and that fixing those is more important. You can't
tell me that the hordes of "gosh, there is a bug in some little game
that is RC since 3 days, with a one-line fix that is already in all
VCSes but in no package because there was no upload for a year,
let's NMU fast" people will suddenly stop reaching for low-hanging
fruits and instead look at bugs that cannot be fixed without looking for
at least a week at it?


> Our current priority system does not fit that task. Because of the rules about
> conflicts, important packages like postfix are of priority extra.

How is postfix important? It's not installed by default, the majority of
people does not need it.
It may be important to you and many other people, but virtually every
package is important to at least one person.

> With a priority system improved along this direction, I think it opens the
> possibility to let some architectures release without the least important
> packages.

What is "let some architecture release" supposed to mean. Being
subscribed to some architecture specific lists, I cannot remember people
active for some architecture ever requesting they do not want some
package. Usually that is the maintainers of the packages that complain
that those architectures are not enough like i386 to simply choke code
that should never had been open source because even the possiblity that
a human would look at it is a crime against humanity.

Not having some package in some architecture makes that architecture
much less attractive, because differences suck. Most people having more
than stuff still booting in 16 bit mode usually have multiple
architectures. Having one Debian that is the same everywhere is a very
big advantage from the point of the user. I cannot imagine some
architecture no longer wanting that, because that would mostly be
suicide.

So is this "let" supposed to mean "allow" or to mean "force"?

We also already have a possiblity to release without some package on
some architecture. Just stop building it and request removal from unstable.
There is a reason we frown upon this. Building stuff everywhere and make
it work everywhere is a big investment in quality and making things fit
for the future. I doubt without years of fixing bugs everywhere to make
things work on alpha (which could be seen to be mostly an architecture
born dead in a commercial sense quite early), introducing amd64 could
have been done thus smootly as it comparatibly was. And all those
alignment issues on most architectures usually also speed up code in
i386 if fixed properly...

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100328105131.ga6...@pcpool00.mathematik.uni-freiburg.de

Re: Question for all candidates: Release process

[Charles Plessy]

Le Sat, Mar 27, 2010 at 01:15:47PM +0100, Stefano Zacchiroli a écrit :
> 
> I don't understand what "cloud computing" has to do with your idea of
> using package priorities to release differently different sub-systems
> within Debian. I'm well aware that we are currently lagging behind in
> the race for OS for the cloud (and we should really catch up, at least
> in terms of visibility), but what it has to do with your idea?

Hi Stefano,

I think that cloud computing participates to create the demand for a Debian
system that offers not only a stable release that lasts years, but also updated
packages that are built or collected for being used with the stable release. A
mirror containing stable, backports, and snapshots is a good first step in that
direction.

The problem of having all backports in one single repostitory is of course that
not all packages have the same needs, which creates incoordinations or
conflicts of interest. Again, I am not saying that it will be the silver
bullet, but a refactored priority and sections system would allow to easily
identify subsets that could have a common policy and an increased effort for
coordination, or in contrary a more unsupervised mode of operation when it
comes to leaf packages (trust the maintainers!).

I do not pretend to offer a complete and robust solution in my platform or the
emails discussed on this list. But I ask the question to the DDs: would you
like to distribute your work differently? If yes, vote for me as a DPL, and
will spend time and energy to help the Project go that way.

(And to answer to the comment ‘you do not need to be DPL for doing this’, that
is true, but if I make a bad score at this election, I will conclude that there
are not many persons interested in what I propose anyway, and will save 
everybody's
time by not discussing them further in the short term.)

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100329015024.gb4...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Charles Plessy]

Le Sun, Mar 28, 2010 at 12:51:31PM +0200, Bernhard R. Link a écrit :
> 
> So is this "let" supposed to mean "allow" or to mean "force"?

Hi Bernd,

it means, the one who wants the package is responsible for it. If upstream and
the maintainer are not interested in supporting a package on an architecture,
and if the porters want the package in their portfolio, then it would be their
responsability to deal with the porting issues. In contrary, if the maintainer
wants the package on an architecture, and the porters are busy with other
tasks, then it would be the responsibility of the maintainer to find help
somewhere else. I do not mean to force people. For the moment the forced people
are the maintainers who have to spend time on architectures where their package
is not used.

This would be much clearer than having three parties that try to throw the hot
potato in each other's hands.


> Building stuff everywhere and make
> it work everywhere is a big investment in quality and making things fit
> for the future. I doubt without years of fixing bugs everywhere to make
> things work on alpha (which could be seen to be mostly an architecture
> born dead in a commercial sense quite early), introducing amd64 could
> have been done thus smootly as it comparatibly was. And all those
> alignment issues on most architectures usually also speed up code in
> i386 if fixed properly...

This is very true, and will provide a motivation for building the package on
non-mainstream architectures, but where my opinion differs is that looking for
new bugs is a task for upstream, not for the pakcage maintainer. I am most
happy to assist upstream in this task, but the motivation has to come from him.


Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100329020628.gc4...@kunpuu.plessy.org

Re: Question for all candidates: Release process

[Paul Wise]

On Mon, Mar 29, 2010 at 9:50 AM, Charles Plessy  wrote:

> (And to answer to the comment ‘you do not need to be DPL for doing this’, that
> is true, but if I make a bad score at this election, I will conclude that 
> there
> are not many persons interested in what I propose anyway, and will save 
> everybody's
> time by not discussing them further in the short term.)

I find that attitude problematic. When electing a DPL we get a package
deal. Some of each candidates ideas are liked by some/many, others
disliked by some/many. It would be a shame to throw out good ideas
with bad ones.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e13a36b31003282003r60f47ee4n69a459f9606b0...@mail.gmail.com

Re: Question for all candidates: Release process

[Joerg Jaspert]

> (And to answer to the comment ‘you do not need to be DPL for doing this’, that
> is true, but if I make a bad score at this election, I will conclude that 
> there
> are not many persons interested in what I propose anyway, and will save 
> everybody's
> time by not discussing them further in the short term.)

Now, I think thats the wrong conclusion. While it should be pretty known
that I am not really a fan of you getting DPL, I have one remark about
the above:

 - A good idea should (unless its constitutional required, but what is?)
   not be bound to a DPL term.
 - A lost election might not mean that the ideas are all bad. (It can
   mean it). It might just mean they are presented wrong, or that
   everyone thinks they got presented wrong/at wrong time/at wrong
   place.

-- 
bye, Joerg
I'm not a bad guy! I work hard, and I love my kids. So why should I
spend half my Sunday hearing about how I'm going to Hell?


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739zjlhra@gkar.ganneff.de

Re: Question for all candidates: Release process

[Charles Plessy]

Le Mon, Mar 29, 2010 at 11:03:00AM +0800, Paul Wise a écrit :
> 
> I find that attitude problematic. When electing a DPL we get a package
> deal. Some of each candidates ideas are liked by some/many, others
> disliked by some/many. It would be a shame to throw out good ideas
> with bad ones.

Le Mon, Mar 29, 2010 at 09:16:41AM +0200, Joerg Jaspert a écrit :
> 
>  - A good idea should (unless its constitutional required, but what is?)
>not be bound to a DPL term.
>  - A lost election might not mean that the ideas are all bad. (It can
>mean it). It might just mean they are presented wrong, or that
>everyone thinks they got presented wrong/at wrong time/at wrong
>place.

Hi Joerg and Paul,

you are completely right, and that why I moderated my comment by finishing it
with ‘in the short term’ :)

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100329072751.ga4...@kunpuu.plessy.org

Re: Question for all candidates: Security team

[Martin Michlmayr]

* Henning Makholm <[EMAIL PROTECTED]> [2005-03-15 12:32]:
> It has been asserted on several occasions over the last few years that
> the security team is overworked and understaffed. This is a problem
> that is hard for the average developer to help with, because someone
> who spontaneously volunteers for the job out of the blue shouldn't be
> entrusted with secrets anyway.

I'll leave your questions to the DPL candidates to them, but I'd like
to point out that your sentence above is factually wrong - I know
there is a common misconception that it's hard to contribute to
security work (and this misconception makes it hard to find
volunteers), but this is not true.

It has been repeatedly pointed out on public mailing lists that you do
not have to be a member of the security team, or even a Debian
developer, to make significant contributions to Debian's security
support.  Most of the security work is tracking vulnerabilities,
finding or backporting patches and preparing packages.  Anyone can do
that, and the security team has invited people to help with these
tasks.  Essentially, you only need a member of the security team to
actually upload the source and publish an advisory, but *everything*
else can be done by other people.  People can:

 - monitor security lists
 - check if bugs reported there apply to Debian
 - file bug reports in the BTS
 - send patches (either by grabbing them from the security lists, from
   other vendors, from upstream, or by writing them)
 - prepare packages
 - draft advisories

See
http://lists.debian.org/debian-devel-announce/2005/03/msg00014.html
(which is about testing but the same applies to stable) and
http://lists.debian.org/debian-security/2001/09/msg00225.html which
give more information.

Furthermore, there has been a long discussion about having a database
to keep better track of security issues.  Matt Zimmerman (or a friend
of his) wanted to work on this, but I'm not sure it ever went
anywhere.  If he has mails outlining what it needs to do someone
could possibly implement it and thereby help the security team.

Finally, there is also a Debian audit project which helps to improve
security in the long run.  http://www.debian.org/security/audit/

(Mail-Followup-To: debian-project since this is imho more appropriate.
maybe even -security but I hope -project will get more people involved
in security work)
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Delegations (was: Re: question for all candidates)

[Anthony Towns]

On Mon, Feb 27, 2006 at 12:18:55PM +0100, Marc 'HE' Brockschmidt wrote:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognized as
> delegates of the DPL? What will you do to clarify the situation?

There are two ways of looking at roles in Debian; as being "maintainer"
of a resource -- whether that be a package, or a web site, or a system,
or something else -- and as being a "delegate" of the DPL with specific
delegated powers.

Traditionally, maintainers have near absolute authority over their
resources, and get to choose who replaces them. Delegates, by contrast,
can be replaced by the DPL on a whim, though rarely are. Those are pretty
extreme differences, and it makes sense for people to prefer to be come
under the heading of "maintainer" in that it gives them more certainty
in fulfilling the role; and given DPLs have traditionally been fairly
reticent about managing delegations, it's also how things have tended
to work in practice.

In the end, I don't think the difference is that important -- whether your
a maintainer or a delegate, it's no good if you go crazy and start doing
horrible things. In so far as maintainers might do bad things with their
packages, we need some way to deal with that anyway, so worrying which roles
are under which heading doesn't seem that important.

So I tend to think the most sensible way of dividing the roles is to
basically say that people who need to use the name "Debian" -- that
is people representing Debian to other organisations, negotiating in
Debian's name, making press releases in Debian's name, or managing what's
available under the debian.org or debian.net domains -- are acting as
a delegate in so far as they're doing that; while people maintaining
resources, such as individual packages, the dak install on ftp-master,
or adminning machines are acting as maintainers.

That's obviously a subtle distinction sometimes -- declining to host
a service on a particular Debian box might normally be a maintainer's
decision, eg, but would impact a delegated decision in so far as it might
prevent that service from being available under the debian.org domain.

On Mon, Feb 27, 2006 at 02:53:02PM +, Ian Jackson wrote:
> I'm not a candidate, but:
> There seems to be no question here at all.  The delegate status was
> always intended to cover (for example) the ftp administrators.

If that's what was intended (and that does reflect my recollection), it's
not what ended up happening. You can go all the way back to September '99
for support for the alternate view, look through the debian-private archives
for the message:

Subject: Re: Yes, Virginia, there is a cabal.
Resent-Date: 16 Sep 1999 06:37:29 -
Resent-Message-ID: <[EMAIL PROTECTED]>

> I have heard some people claim that this is not the case and that
> somehow some of the teams like the release and ftp teams are not
> answerable to anyone.  This is patent nonsense.

Maintainers are answerable to the technical committee in a few ways
("decide on any matter of technical policy", "...any technical matter
where Developers' jurisdictions overlap", and "overrule a developer"),
presuming we don't decline to consider the issue on the grounds it's
insufficiently technical.

> Branden seemed to be suggesting that he would formally issue a
> statement saying that certain people were delegates.  I think that
> would have been a mistake.

One issue with delegations is that only grant extra powers, not extra
responsibilities. So when they're removed, only those extra powers
disappear... If they weren't needed in the first place, does that actually
provide any accountability?

Cheers,
aj


signature.asc
Description: Digital signature

Delegation (was Re: question for all candidates)

[Steve McIntyre]

Marc 'HE' Brockschmidt wrote:
>
>Heya,
>
>Two years ago, Branden Robinson talked about the issue of some tasks
>in the project that are neither delegated by the Project leader nor
>covered by the Constitution directly. [1] He referenced his platform
>from 2004 last year (when he was elected), but it seems that nothing
>has happened since then.
>
>So, to the question:
>Should we amend our constitution to reflect how Debian is structured
>in reality, or should the people doing these tasks now be recognized
>as delegates of the DPL? What will you do to clarify the situation?

It's not clear that everybody doing the core jobs in Debian was ever
explicitly delegated by a DPL, but in my opinion that doesn't really
matter. This is for a couple of reasons:

  1. As I see it, the constitution does not require that all roles
 need be delegated. The way that most of Debian has always worked
 is that jobs are done by the people with the skills and (more
 importantly) the desire to do them.

  2. The people doing core tasks are still answerable to the rest of
 the project, regardless of whether they may have been delegated
 or not.

Making an issue of "delegation" would seem to just be a way of causing
aggravation for no good reason. If people believe there is a reason,
then that would be the time to have open and honest discussion on the
subject.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: Digital signature

Re: Question for all candidates: pushing people

[Raphael Hertzog]

On Fri, 16 Mar 2007, Andreas Schuldei wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [070316 14:35]:
> > > How would other candidates avoid dropping topics like this?
> > 
> > The only way you can do that is by actively asking people to produce a
> > report when they said they'd do so.
> 
> that sounds to me like you wanted to continue with "but you cant
> do thatas they are all volunteers and you cant push them" or so.
> could you elaborate? were you in the position to push people to
> do something in debian, and how did you do it? how was your
> success rate? 

You can't "push" people, you can only "direct" them in a direction that
they have nothing against. Some people offered help for Alioth and I could
successfully direct them so that their work matched mostly what I would have
done myself. Others tried to impose their views and we haven't achieved
anything together.

Inside the Alioth team itself, I tend to defer gforge specific issues to
Roland, so I'm sometimes poking him into doing some specific work. It
always looks like a gentle question "Would you have time to work on X ?"
or "Have you noticed X ? Do you think that you can do something about that
sometimes this week ?" or "Can you take a look at your assigned high priority
support request, there are some easy items that I would really like to
get rid of". It tends to work quite well. Roland is a very good team player.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question for all candidates: pushing people

[Wouter Verhelst]

On Fri, Mar 16, 2007 at 03:03:05PM +0100, Andreas Schuldei wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [070316 14:35]:
> > > How would other candidates avoid dropping topics like this?
> > 
> > The only way you can do that is by actively asking people to produce a
> > report when they said they'd do so.
> 
> that sounds to me like you wanted to continue with "but you cant
> do thatas they are all volunteers and you cant push them" or so.

Eh, I really didn't mean anything more than what I said. You can't force
people to do anything, and I won't; but if they volunteer to do
something and then fail to do so, I don't think it's bad to remind them
every once in a while.

> could you elaborate?  were you in the position to push people to do
> something in debian, and how did you do it? how was your success rate? 

I've had to ask people to please please please finally submit their
abstracts and bios and whatnot for the FOSDEM website. It works better
with some people than with others, but eventually most people gave me
what I needed. In a case where you're asking people something they only
can give you, it sucks if they don't do it; but in most cases (like,
say, a report of the Summer of Code), it's quite eaisily possible to ask
someone else to do it.

-- 
 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: Question for all candidates: pushing people

[Steve McIntyre]

On Fri, Mar 16, 2007 at 03:03:05PM +0100, Andreas Schuldei wrote:
>
>that sounds to me like you wanted to continue with "but you cant
>do that???as they are all volunteers and you cant push them" or so.
>could you elaborate? were you in the position to push people to
>do something in debian, and how did you do it? how was your
>success rate? 

I've been in positions where I need to push people to help get jobs
done quite a few times in Debian. I'm normally quite successful at
using gentle, friendly prodding to get things moving along. As we
*are* volunteers, I have also had a few situations where the other
people involved have not got back to me, and after a few more attempts
at pushing I've been forced to accept that they've lost
interest. Typically in those situations the next move is to find
somebody else to help or try and do it myself.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll


signature.asc
Description: Digital signature