Re: Technical committee resolution

[Manoj Srivastava]

On Fri, 14 Mar 2008 22:55:37 -0400, Thomas Bushnell BSG <[EMAIL PROTECTED]> 
said: 
 
> Unfortunately, it seems to me that currently the project has no way of
> dealing with people who refuse to look at new ways of doing things.

Sure. The project has no way of dealing with people who are
 supremely susceptible to argumentum ad antiquitatem.

We also do not know how to deal with people who are susceptible
 to argumentum ad novitatem.

Or argumentum ad populum, argumentum ad numerum, Argumentum ad
 ignorantiam  ...

Your point is?

> It is true that "drop the oldest person" is randomish.  What we have
> now is *equally* random; it presumes that the person already on the
> committee is a better member than anyone else that could be found.

Hmm? I am not sure who else but you is making the argument,
 really.  There has always been support for selecting the "best" person
 once can convince to serve. However, in Debian, as in many volunteer
 organizations, there are a lot of people serving in official capacities
 in Debian who are indeed not better than anyone else that can be found.
 They merely happen to have stood up to be counted, and often are doing
 a good enough job -- and we certainly do not turf such volunteers f
 there are "better" people who can possibly be found.

All this replacement in favour of a better person sounds very
 nasty, mean, and likely to be highly subjective to me, and most
 organizations do not often throw people out while they are still
 performing their duties.

The tech ctte has apparently not being measuing up -- so we
 should first look to see who has not participating, and use that as a
 criteria for determining who to replace.

The creiteria can be more than just voting on issues -- look for
 number of emails on threads on a issue raised, number of emails sent to
 the bug report, number of "fact finding" or "research" or survey or
 report mails in that mix.

> I suggest that the best way to have good people on the committee is to
> have some process by which one person or group of people get to decide
> that it's time to replace person X with person Y, and not simply wait
> around for person X to resign.

Sure. As long as we are not just flipping coins or tossing dice.
 My objection has always been to the dice rolling bits, not the
 debriding of the ctte.

And we did not always wait for people to resign.  Gentle
 prodding with the prospect of unilateral action to remove has worked in
 the past.

manoj
-- 
To program is to be.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: All Candidates: Do you plan to be prominently visible during your term?

[Holger Levsen]

Hi,

On Saturday 15 March 2008 22:40, Marc Haber wrote:
> Additionally, it may be a good idea to have regular "IRC conferences"
> where the DPL is available to answer questions. A good time would
> probably be a week after bits have been posted so that the questions
> that the bits have raised can be answered. But that's only an idea,
> not a "must", as long as the regular "bits" actually appear.

I actually like the idea. "IRC conference" might sound a bit too much, rather 
something like "IRC feedback time" or such... 

I think by making it less formal, its more likely the DPL wants to do such a 
thing :-)

OTOH, anyone can reply via mail to the bits... hm.


regards,
Holger


pgpkFkTRmwpdK.pgp
Description: PGP signature

Re: Technical committee resolution

[Thomas Bushnell BSG]

On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
> All this replacement in favour of a better person sounds very
>  nasty, mean, and likely to be highly subjective to me, and most
>  organizations do not often throw people out while they are still
>  performing their duties.

Of course it's "subjective."  So what?  The question is whether good
decisions are made, not whether we can always find clear objective
criteria for them.  Debian has often been hampered by a refusal to make
good subjective decisions, because of the hamstringing character of
those who insist on deductive proofs before steps can be taken.

My question was specifically about whether you would support an
amendment that allowed throwing people out when they were *not* doing
their duties.  Would you?

> The creiteria can be more than just voting on issues -- look for
>  number of emails on threads on a issue raised, number of emails sent to
>  the bug report, number of "fact finding" or "research" or survey or
>  report mails in that mix.

Quite right: that's why I suggested that if someone has failed to vote
or contribute twice, they should be replaceable at the option of the
DPL.  If someone fails to vote that's clear; if someone fails to
contribute (you mention a number of relevant factors) it's harder to
quantify and so I suggested any two of DPL, Project Secretary, or Tech
Ctte Chair could certify that a member had failed to contribute to a
decision.

Thomas



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

Re: Question for all candidates: inter-dependancy of works the growing Debian project.

[Moritz Muehlenhoff]

Charles Plessy wrote:
> I started to wonder about modularity in the use of the Debian
> infrastructure in 2006, because of a problem with the clustalw package.
> As you can see on the graph, its popcon score started to decrease around
> july. 
> (http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clustalw)
> I found out that it correlated with a bug whose fix was kept in unstable
> because it was not built on some arches (clustalw is non-free). This was
> a frustrating experience: I had strong evidence that we were losing
> users and it took me many hours of efforts to get it built on the
> missing arches, on which I have never had heard of anybody using
> Clustal. The popcon scores restarted to increase shortly after a
> re-upload with version bump triggered the release.net autobuilders.

Since there's an opt-in auto-build service for non-free these days,
this should be resolved already.

> There is something interestign in this example: it shows the case of
> alternative services offered to a package maintainer (although one is
> not official). Both have similar functions, but their requisites are not
> the same (building non-free on official autobuilders is not allowed).
> When I talk about componentisation, I simply mean that the fate of a
> package could be the result of multiple bilateral agreements between
> teams. If there is build team A and build team B, then the package
> maintainer could collaborate with one or the other. It is not necessary
> competition: Debian will in the future release team S, release team B,
> release team V, like Stable, Backports, Volatile. For security support,
> the Security team has very high standards that do not necessary fit all
> packages (see the wordpress controversy for instance). Having either
> alternative security teams or schemes like "upgrade" or "best efforts"
> would allow to better fit upstream's strategy for instance.

There are only a few packages, which are affected by this and most
of these are handled on a case-by-case basis already, e.g. the way
Mozilla security updates are handled in Etch.

Security-wise, there's already ongoing (although currently stalled)
work to classify security support level deviations using debtags.
However, consistent quality across our (huge) archive is one of our
greatest strengths, so this needs to be handled with great care
and proper support in our package management toolchain.

Cheers,
Moritz


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

Re: Technical committee resolution

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [080316 21:01]:
> On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
> > The creiteria can be more than just voting on issues -- look for
> >  number of emails on threads on a issue raised, number of emails sent to
> >  the bug report, number of "fact finding" or "research" or survey or
> >  report mails in that mix.
> 
> Quite right: that's why I suggested that if someone has failed to vote
> or contribute twice, they should be replaceable at the option of the
> DPL. 

I would prefer if people would fix their release goal / critical bugs
instead of preparing complex arguments how to change the tech ctte at
places where it is not broken.


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


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

Re: Technical committee resolution

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [080317 00:24]:
> 
> On Mon, 2008-03-17 at 00:13 +0100, Andreas Barth wrote:
> > * Thomas Bushnell BSG ([EMAIL PROTECTED]) [080316 21:01]:
> > > On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
> > > > The creiteria can be more than just voting on issues -- look for
> > > >  number of emails on threads on a issue raised, number of emails sent to
> > > >  the bug report, number of "fact finding" or "research" or survey or
> > > >  report mails in that mix.
> > > 
> > > Quite right: that's why I suggested that if someone has failed to vote
> > > or contribute twice, they should be replaceable at the option of the
> > > DPL. 
> > 
> > I would prefer if people would fix their release goal / critical bugs
> > instead of preparing complex arguments how to change the tech ctte at
> > places where it is not broken.
> 
> I see; so there are no members of the technical committee who have
> failed twice to vote?

I'm not sure how not voting twice in a row makes someone a less
important contributor by definition.

But I would really prefer if you would fix your own packages instead of
relaying on our BSPers.



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


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

Re: Technical committee resolution

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 00:13 +0100, Andreas Barth wrote:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) [080316 21:01]:
> > On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
> > > The creiteria can be more than just voting on issues -- look for
> > >  number of emails on threads on a issue raised, number of emails sent to
> > >  the bug report, number of "fact finding" or "research" or survey or
> > >  report mails in that mix.
> > 
> > Quite right: that's why I suggested that if someone has failed to vote
> > or contribute twice, they should be replaceable at the option of the
> > DPL. 
> 
> I would prefer if people would fix their release goal / critical bugs
> instead of preparing complex arguments how to change the tech ctte at
> places where it is not broken.

I see; so there are no members of the technical committee who have
failed twice to vote?

Thomas



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

Re: Technical committee resolution

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote:
> > I see; so there are no members of the technical committee who have
> > failed twice to vote?
> 
> I'm not sure how not voting twice in a row makes someone a less
> important contributor by definition.

I see; so what number do you think would be wise?  Two was just a
starting point; I'm not wedded to that.  How many votes or conversations
should a member be able to miss before it is clear he or she is not
participating reliably enough?

What do you think about the three-month suggestion?  If that's a bad
time limit, what would be a better one?

> But I would really prefer if you would fix your own packages instead of
> relaying on our BSPers.

I'm not sure how this is relevant to the tech ctte.  Can you explain it?

Maybe we should have BSPers for the tech-ctte, so that if the committee
is too busy in a particular week other people can step in and do that
work.

Thomas



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

Re: Technical committee resolution

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote:
> But I would really prefer if you would fix your own packages instead of
> relaying on our BSPers.

Actually, I'm very good about uploading fixes for RC bugs promptly.  The
bugs I think you are referring to were marked severity "important".
Perhaps the bugs were tagged incorrectly?  I must have missed the change
in the release goals to require GCC 4.3 when it came out.  If the bug
had been tagged "serious" I would have uploaded the fix as soon as
possible.

Thomas



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

On RC/RG bugs…

[Cyril Brulebois]

On 17/03/2008, Thomas Bushnell BSG wrote:
> Actually, I'm very good about uploading fixes for RC bugs promptly.
> The bugs I think you are referring to were marked severity
> "important".  Perhaps the bugs were tagged incorrectly?

Severity != tag. And the severity is correct.

> I must have missed the change in the release goals to require GCC 4.3
> when it came out.  If the bug had been tagged "serious" I would have
> uploaded the fix as soon as possible.

You don't read debian-devel-announce, do you?

-- 
Cyril Brulebois


pgpPu53fo9L3x.pgp
Description: PGP signature

Re: On RC/RG bugs…

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 02:46 +0100, Cyril Brulebois wrote:
> On 17/03/2008, Thomas Bushnell BSG wrote:
> > Actually, I'm very good about uploading fixes for RC bugs promptly.
> > The bugs I think you are referring to were marked severity
> > "important".  Perhaps the bugs were tagged incorrectly?
> 
> Severity != tag. And the severity is correct.

I thought all RC bugs were supposed to have severity "serious" or
higher.  Has that been changed?  Sorry, I used the word "tagged"
imprecisely; I meant "labelled."

> > I must have missed the change in the release goals to require GCC 4.3
> > when it came out.  If the bug had been tagged "serious" I would have
> > uploaded the fix as soon as possible.
> 
> You don't read debian-devel-announce, do you?

Of course I do.  What I said was that I must have missed the
announcement.

And what exactly does this have to do with the technical committee?

Thomas



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

Re: On RC/RG bugs…

[Cyril Brulebois]

Please respect list policies and don't duplicate mails.

On 17/03/2008, Thomas Bushnell BSG wrote:
> I thought all RC bugs were supposed to have severity "serious" or
> higher.  Has that been changed?

RC != RG.

> > You don't read debian-devel-announce, do you?
> 
> Of course I do.  What I said was that I must have missed the
> announcement.

Then please refer (again) to e.g.:
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]


> And what exactly does this have to do with the technical committee?

No idea. It looks like it all started with
[EMAIL PROTECTED], and since you're still
wondering about RC/RG bugs, I'm answering these questions.

-- 
Cyril Brulebois


pgp8ZZbMd4K90.pgp
Description: PGP signature

Re: On RC/RG bugs…

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote:
> On 17/03/2008, Thomas Bushnell BSG wrote:
> > I thought all RC bugs were supposed to have severity "serious" or
> > higher.  Has that been changed?
> 
> RC != RG.

Ah, well then there is no need to berate me for failing to fix the bug
immediately.  I'm grateful for those NMUers who helped me out, but there
was no particular urgency to the bug.  

> > > You don't read debian-devel-announce, do you?
> > 
> > Of course I do.  What I said was that I must have missed the
> > announcement.
> 
> Then please refer (again) to e.g.:
>   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]

As soon as the NMU was uploaded I checked the release goals and verified
it myself, thanks.  

Thomas



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

Re: On RC/RG bugs…

[Thomas Bushnell BSG]

On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote:
> > And what exactly does this have to do with the technical committee?
> 
> No idea. It looks like it all started with
> [EMAIL PROTECTED], and since you're still
> wondering about RC/RG bugs, I'm answering these questions.

It would be a shame to think that the subject was brought up only to
distract attention from the actual topic relevant for debian-vote.  I
remain sure that this cannot have been Andreas' goal, but what the
connect is that he must have had in mind does elude me.

Andreas, can you explain the relevance to the tech-ctte discussion?

Thomas



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