Re: Question for all candidates: Handling declassification of debian-private (GR 2005-02)

[Marc 'HE' Brockschmidt]

Steve McIntyre <[EMAIL PROTECTED]> writes:
> On Wed, Mar 12, 2008 at 03:21:23PM +0100, Raphael Hertzog wrote:
>>On Tue, 11 Mar 2008, Fabian Fagerholm wrote:
>>> If you were elected DPL for the next term, what would you do about this
>>> GR and when? How would you ensure that the declassification can happen
>>> in a timely manner and fulfil all the requirements? What would your
>>> declassification team look like -- how many members would it have, how
>>> would they be selected and would you impose any structure among them?
>>I would _not_ organize this myself. The DD who are interested in
>>declassification of those mails should come up with a proposition
>>and I'll gladly bless them (if it doesn't contain anything
>>objectionable - that said I don't see what could go wrong).
> Without wishing to just add  here, I think Raphael and I are in
> broad agreement. I'm not going to treat the declassification effort as
> a personal priority, but I'd love to hear from people who would like
> to get involved. If I can help them get the job done (resource
> allocation, delegation, etc.) then so much the better.

For the sake of completness: I would need to put a "ME TOO 1"
here. The declassification of -private mail will involve big amounts of
manual work. The DPL can't force people to do so, so we just need to
wait for someone to come forward interested in doing this and then
provide as much help as possible.

Marc
-- 
BOFH #55:
Plumber mistook routing panel for decorative wall fixture


pgpmDQwQZ2Jgq.pgp
Description: PGP signature

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

[Raphael Hertzog]

On Thu, 13 Mar 2008, Charles Plessy wrote:
> (And since this thread is supposed to be questions for the DPL
> candidates, I will add one: some time ago, a DD was sending emails on
> -devel whenever the discussion was offtopic, to ask for it to be
> transferred or stopped: what do you think of this initiative ?).

It's Michael Banck (azeem). Some reminders are welcome because the
population evolves and even old members tend to forget where they're
speaking and don't ask themselves if they're still on-topic.

However too many reminders are just noise.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Q: Marc Brockschmidt: "tight-knitted groups of friends"

[Marc 'HE' Brockschmidt]

Clint Adams <[EMAIL PROTECTED]> writes:
> Your platform contains the following claim:
>> This can hardly be solved from the outside - but a start would be to 
>> not defame these groups as "evil cabals" hindering the rest of the 
>> project out of spite.
> Why can "this" not be solved from the outside?

One possible way out of this is replacing the whole team, but the
entailed pain in the transition period and the loss of experience is
usually too big to make complete replacement a viable option. OTOH,
experience shows that enforced addition of new members doesn't work as
one would expect. The usual pattern is that old members end up in a
closed circle of "masters", while the new members get to help as
"assistants", ensuring that the additional help can't actually help with
all tasks. 
As we are working with volunteers here, there's no real way to enforce a
change in this pattern, so the only option left is constant constructive
criticism with an emphasis on the fact that letting new people in could
solve most issues. Flaming usually just wastes everyones time and only
makes the involved parties resent changes more than before.

Marc
-- 
BOFH #288:
Hard drive sleeping. Let it wake up on it's own...


pgp8CVuEGiESi.pgp
Description: PGP signature

Re: Q: Marc Brockschmidt: "tight-knitted groups of friends"

[cobaco (aka Bart Cornelis)]

On Thursday 13 March 2008, Clint Adams wrote:
> How will not defaming contribute to a solution?

I thought that one obvious: 

defaming makes people feel attacked, and thus encourages flaming and 
reacting on an emotional basis instead (or in addition to) a rational one.

-> it's not so much that 'not defaming' actively helps, as that it avoids
   creating additional barriers
-- 
Cheers, cobaco (aka Bart Cornelis)


signature.asc
Description: This is a digitally signed message part.

Re: Q: Raphaë l Hertzog: dpkg / collab-maint

[Raphael Hertzog]

Hi Clint,

On Wed, 12 Mar 2008, Clint Adams wrote:
> Why isn't dpkg in collab-maint on Alioth? Why should it be or not be?

dpkg has been maintained in various VCS repositories since 1999 (CVS, then
arch, then SVN, and now Git), it's a natural choice for a software
maintained and further developed by several persons.

collab-maint's purpose is to work collaboratively on the _packaging_
of (upstream) software for Debian. Even though packaging sometimes
involves modifying the software, it's not really comparable to the work
done by the upstream author of a given software. Thus I believe that
it's just right for dpkg to have its own repository.

It's important to have quality and consistency in the work done on such a
package and thus it's good that the maintainers in charge can selectively
grant (and revoke) write rights to the repository.

> As DPL, how would you react to the recent events concerning dpkg
> development?

Honestly, it's difficult to say as I'm too much involved. Maybe the
opinion of Moritz and Lucas would be more interesting on this particular
event.

That said, (at the beginning) I was not directly concerned by the problem
(which is mainly between Ian and Guillem): I jumped in because I want to
see the triggers merged and I want(ed) Ian to be able to help us
effectively. I invested lots of hours to explain to Ian how I have been
able to join the dpkg team and what kind of interactions were
expected/needed. 

In the latest discussions (see
http://people.debian.org/~hertzog/debian-dpkg.log) I have been as far as
telling him that I would support his inclusion on the team provided he
respected some rules:
- review with other members before merge of any big branch
- proper git commit logs
- rebase of small patches before pushing

I believe I have tried my best to prevent the problem by talking both to
Ian and to Guillem, obviously it has not been as successful as I hoped.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Q: Raphaë l Hertzog: dpkg / collab-maint

[Raphael Hertzog]

On Thu, 13 Mar 2008, Raphael Hertzog wrote:
> It's important to have quality and consistency in the work done on such a
> package and thus it's good that the maintainers in charge can selectively
> grant (and revoke) write rights to the repository.

Following a remark on IRC, it's also important to have quality and
consistency in the packaging of (external) software. But the lack of
quality in dpkg has far more consequences than the lack of quality in
the packaging of a random package.

Furthermore the average skillset of the DD includes packaging while it
doesn't necessarily include programming and maintaining a complex piece of
software like dpkg.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Q: Raphaë l Hertzog: dpkg / collab-maint

[Julien Cristau]

On Thu, Mar 13, 2008 at 12:14:22 +0100, Raphael Hertzog wrote:

> Furthermore the average skillset of the DD includes packaging while it
> doesn't necessarily include programming and maintaining a complex piece of
> software like dpkg.
> 
Doesn't the average skillset of a DD include knowing not to touch a
complex piece of software like dpkg if he's not skilled enough?
If not, shouldn't the average DD be also prevented from NMUing a complex
piece of software like dpkg?

Cheers,
Julien


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

Re: Technical committee resolution

[Manoj Srivastava]

On Thu, 13 Mar 2008 14:37:46 +1000, Anthony Towns <[EMAIL PROTECTED]> said: 

> On Tue, Mar 11, 2008 at 06:54:50PM +, Ian Jackson wrote:
>> And, just to make things personal, I submit that one of the problems
>> is AJ.

> Because, of course, making things personal is definitely what the
> technical committee is all about, and just generally a brilliant
> approach to solving problems.

And yet,  further down, you respond in kind.[0]

>> AJ says that what is needed is `new blood'.  I suspect that part of
>> what he means is that he wants rid of me.

> I don't think the committee would be worse off without you; and I find
> it fundamentally disturbing that any of the founding members are still
> members ten years later. The same's true of Manoj (though I'm not sure
> if he joined when the committee was formed, or shortly after
> that). Even ftpmaster has changed significantly more than that over
> the same time period, for example.

This I don't understand.  This seems like a blend of appeal to
 novelty and a personal vendetta; which makes me very uneasy about
 supporting the proposal. Of course, appeal to tradition is equally
 silly; and I am certainly not proposing that.

When I championed the last injection of fresh blood into the
 ctte,  we also reduced the membership of the ctte; and the criteria we
 selected for removal was  participation, and thus contribution to the
 committee; and all the people thus removed were pinged, and were indeed
 in agreement.

And oh, yes, I have been on the ctte since it was formed; though
 I was not initially on the draft short list of proposed members.

> I also think you're completely off the wall in many of your opinions,
> including your desire to have Debian ship a different md5sum compared
> to everyone else, to have further discussion about Sven's proposal for
> a libstdc++ udeb, and your latest obsession with taking dpkg back
> over, and I think you set an incredibly bad example in the way you
> deal with conflicts. I don't have much of a problem with that, though,
> because the committee is meant to be a group that makes decisions, and
> it's good to have people with different opinions and approaches in a
> group.

> It would certainly be possible to argue that you're the main problem
> with the committee -- you proposed it while DPL, you've been on it for
> its entire existance, and you chaired it for a good five years by my
> count: at the very least, you've had more of an opportunity to ensure
> it's functional than anyone else in the project, and thus are the
> individual who ought to be held most responsible for its
> dysfunctionality.


 0: This is what I mean.

> But even if you were to not only argue that but buy into it, there's
> still a structural problem that the tech ctte membership isn't
> answerable to anyone else, and the project doesn't have any influence
> over its membership.

This is the first valid point I have seen in favour of the
 proposal. 

> The reason I didn't raise this last year was because the only
> reasonable path to removing members seems to me to be oldest first,
> and I was pretty sure you'd take that personally; given you're
> decision to hijack dpkg over coding style preferences, I find I'm not
> so bothered by what you think anymore.

Actually, basing removal on term of service seems to be the
 least logical of the replacement strategies;  since it care anught for
 performance, or value of the contribution, but seems to cater to
 novelty for novelties sake.

manoj
-- 
Law stands mute in the midst of arms. Marcus Tullius Cicero
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: Q: Raphaë l Hertzog: dpkg / collab-maint

[Raphael Hertzog]

On Thu, 13 Mar 2008, Julien Cristau wrote:
> On Thu, Mar 13, 2008 at 12:14:22 +0100, Raphael Hertzog wrote:
> 
> > Furthermore the average skillset of the DD includes packaging while it
> > doesn't necessarily include programming and maintaining a complex piece of
> > software like dpkg.
>
> Doesn't the average skillset of a DD include knowing not to touch a
> complex piece of software like dpkg if he's not skilled enough?

It does and it works quite well (I have not yet seen a single complaint
concerning collab-maint or projects which have granted write access to all
DD through ACL). But I see no valid reason to change the current situation
for dpkg (and even more in light of the recent events).

I doubt that the lack of commit access prevented anyone to start
contributing for instance. 

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Technical committee resolution

[Manoj Srivastava]

Hi,

For the record, I have already engaged in this "get new blood
 into the ctte"  experiment, conducted two years ag, when I championed
 the new inductees into the ctte.

I must say, the track record of new blood has been, in my
 opinion, mostly positive, but the overall performance of the ctte
 apparently has not  improved enough.

Redoing the new blood thing once again is unlikely to  have much
 of an effect, really. I think we need to find some of the root causes
 of the malaise that affects this institution, and fix that, rather
 than rampaging around rearranging things randomly like a bull in a china
 shop.

manoj
-- 
HELP I'm being held prisoner in /usr/games/lib!
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: Technical committee resolution

[Anthony Towns]

On Wed, Mar 12, 2008 at 10:36:38PM -0700, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > I don't think the committee would be worse off without you; and I find
> > it fundamentally disturbing that any of the founding members are still
> > members ten years later.
> I think this sentence strikes at the core of my reservations about this
> proposal.  The whole thing feels like an appeal to novelty fallacy.  

Well, if you assume change isn't going to change anything, then, well,
I guess you've got your conclusion.

Personally, I find that a fallacy in and of itself, though.

There's two fundamental things that persuade me. First, change doesn't
just happen, it takes people to cause it; and different people will cause
different changes. The current crop of people have had their go -- all
the current members have been on the technical committee in excess of
two years, half in excess of six years. And their ideas haven't brought
a lot of success to the committee; but _even if they had_ it would be
time to try a new set of ideas.

A good formula for almost everything is:

Keep the things that have already been tried that worked.
Try new things.
Repeat.

Calling novelty a fallacy is just crazy if you ask me. *shrug*

The second aspect is there are three levels of "problem" involving people
or personalities:

1. No problem, everything's fine, keep on keeping on!
2. Some problem, but not enough to cause a fuss
3. Major problems, where doing something about them can't be avoided

If you don't have a no-fault means of transitioning people, problems in
the second class don't get fixed, and Debian has a pretty strong tradition
of considering as many problems as possible in case (2) rather than (3).

It takes a _lot_ to remove someone for cause in Debian -- see the DPL
recall vote, or any of the expulsions we've had, or any of the groups that
haven't changed membership for a while in spite of complaints about the
job they're doing and how others could do it better. Having a mechanism
to regularly transition people without fault is an important safety valve.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Technical committee resolution

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> There's two fundamental things that persuade me. First, change doesn't
> just happen, it takes people to cause it; and different people will
> cause different changes. The current crop of people have had their go --
> all the current members have been on the technical committee in excess
> of two years, half in excess of six years. And their ideas haven't
> brought a lot of success to the committee; but _even if they had_ it
> would be time to try a new set of ideas.

Again, the rest of the paragraph is somewhat reasonable, although I don't
think it's as persuasive as you think it is.  But that last clause is
simply wrong.  You can count on my vote against any proposal that changes
things just for the sake of changing things.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Technical committee resolution

[Manoj Srivastava]

On Thu, 13 Mar 2008 17:01:01 +1000, Anthony Towns <[EMAIL PROTECTED]> said: 



> It takes a _lot_ to remove someone for cause in Debian -- see the DPL
> recall vote, or any of the expulsions we've had, or any of the groups
> that haven't changed membership for a while in spite of complaints
> about the job they're doing and how others could do it better. Having
> a mechanism to regularly transition people without fault is an
> important safety valve.

Let me get this straight. The argument is that since it is hard
 to remove people for cause in Debian, let us just start removing people
 at random, even if they are performing well, and maybe, sometime,
 somehow, that change may lead to an improvement?


And this is not argumentum ad novitatem, somehow?

manoj
-- 
Timing must be perfect now.  Two-timing must be better than perfect.
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: Technical committee resolution

[Ian Jackson]

Julien Cristau writes ("Re: Technical committee resolution"):
> On Tue, Mar 11, 2008 at 20:03:57 -0400, Hubert Chathi wrote:
> > OK, the rest of your mail sounds somewhat reasonable, to an outsider who
> > has no experience whatsoever with TC, but ... given that the TC often
> > deals with contentious issues, and there is no obvious "right" or
> > "wrong", how would you measure how often a TC member is "wrong"?  Who
> > determines if they're wrong?  Or am I missing something?
> 
> "wrong" in this context means "disagrees with Ian".

Well, I said
 We should be removing TC members who are ... often wrong.

I'm sure everyone will agree with that statement put like that.

My opinion comes into it when I ask myself `who is ... often wrong'.
And I don't expect anyone has a very different definition of `this
person is often wrong' to their own definition of `this person often
disagrees with me'.

So from AJ's point of view I'm sure he's got me in his sights as
someone who should go.  Because he thinks I'm often wrong.

Ian.


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

Re: Technical committee resolution

[Ian Jackson]

Manoj Srivastava writes ("Re: Technical committee resolution"):
> Redoing the new blood thing once again is unlikely to  have much
>  of an effect, really. I think we need to find some of the root causes
>  of the malaise that affects this institution, and fix that, rather
>  than rampaging around rearranging things randomly like a bull in a china
>  shop.

Absolutely.

Ian.


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

Re: Technical committee resolution

[Ian Jackson]

Anthony Towns writes ("Re: Technical committee resolution"):
> Well, if you assume change isn't going to change anything, then, well,
> I guess you've got your conclusion.

That's a completely wrongheaded way of looking at it.
We (Manoj, Russ, I, and perhaps others) are not opposed to change.
It must be quite clear that I'm unhappy with the way the TC has been
functioning and that I would like to see change.

The question is _what kind of change_ should we introduce, to have the
desired effect ?  We are unconvinced that your proposals will.

To characterise that as "change isn't going to change anything" is
absurd.  What we're saying is that _your proposed changes_ don't seem
likely to result in an _improvement_.

Until we get past this "people who don't agree with me are just
opposing change" nonsense it will be impossible to have a rational
conversation about what the real problems are and how to fix them.

Ian.


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

Re: Technical committee resolution

[Frans Pop]

Ian Jackson wrote:
> Well, I said
>  We should be removing TC members who are ... often wrong.
> 
> I'm sure everyone will agree with that statement put like that.
> 
> My opinion comes into it when I ask myself `who is ... often wrong'.
> And I don't expect anyone has a very different definition of `this
> person is often wrong' to their own definition of `this person often
> disagrees with me'.
> 
> So from AJ's point of view I'm sure he's got me in his sights as
> someone who should go.  Because he thinks I'm often wrong.

What I am missing in this whole discussion is some introspection and
self-reflection from the current TC members who have participated:
- how happy is each with the way _he himself_ has functioned over the past
  two years or so?
- has _he himself_ participated in both discussions and votes as befits an
  active member of a team?
- does he think _he himself_ has contributed enough to the analysis and
  resolution of issues

I think that some members, if they are truly honest with themselves, should
come to the conclusion that it might be better to free their position for
someone else.

Cheers,
FJP


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

Re: Technical committee resolution

[MJ Ray]

Manoj Srivastava <[EMAIL PROTECTED]> wrote: [...]
> Let me get this straight. The argument is that since it is hard
>  to remove people for cause in Debian, let us just start removing people
>  at random, even if they are performing well, and maybe, sometime,
>  somehow, that change may lead to an improvement?

Firstly, it's not random.  It's the oldest.  Maybe random wouldn't be
so objectionable.  Genetic algorithm optimisation of the TC, anyone?

Secondly, they can be reappointed if they are performing well, unless
the DPL is going to ignore procedure and go against the consensus of
DDs - it's happened before, but it's never good when it happens.

Thirdly, if this is a major problem with the proposal, one could
support Andreas Barth's amendment, or propose another amendment which
uses another form of selection.  Other TC members can suggest text
too, unless all's well with the TC and it can be improved without the
pain of a vote, which would be great.

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Technical committee resolution

[Manoj Srivastava]

On Thu, 13 Mar 2008 23:07:09 +, MJ Ray <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote: [...]
>> Let me get this straight. The argument is that since it is hard to
>> remove people for cause in Debian, let us just start removing people
>> at random, even if they are performing well, and maybe, sometime,
>> somehow, that change may lead to an improvement?

> Firstly, it's not random.  It's the oldest.  Maybe random wouldn't be
> so objectionable.  Genetic algorithm optimisation of the TC, anyone?

As there seems to be no corelation at all between the algorithm
 used and the problem at hand, it is random -- insofar as in that the
 results can not be predicted.

An alternative is to throw out the member who is youngest.  Or
 use birth month to throw out -- the members born later in the
 year should be thrown out first.  Or people born in odd number years
 go first.

All thse are equally silly. And selectingone algorithm or the
 other with no regards to if they have any bearing on the solution, or
 have any rationale for actually improving things seems exactly to be an
 argument in favour of novelty.

Why is no one responding to the fact that the last ingestion of
 new blood did not solve the problems?  Is the argument that the new
 blood selected was the wrong bunch of new blood, and in that case we
 should perhaps also consider purging the new blood, since they did not
 actually help solve the issues?

Hey. I like the algorithm of slinging out newest members. Silly,
 yes, but no sillier than the proposals at hand.

 {proposing and selecting silly algorithms for arbitarily churning the
 ctte membership elided]

manoj
-- 
Consultant, n.: An ordinary man a long way from home.
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: Technical committee resolution

[Anthony Towns]

On Thu, Mar 13, 2008 at 06:32:13PM -0500, Manoj Srivastava wrote:
> An alternative is to throw out the member who is youngest.

No, that would again ensure stagnancy in the group, with the older members
being permanently appointed.

>  Or use birth month to throw out

Likewise.

> -- the members born later in the
>  year should be thrown out first.  Or people born in odd number years
>  go first.

"Odd number years" doesn't give a complete ordering; what happens once all
the members are born in even numbered yearS?

> All thse are equally silly. And selectingone algorithm or the
>  other with no regards to if they have any bearing on the solution, or
>  have any rationale for actually improving things seems exactly to be an
>  argument in favour of novelty.

The fallacy of argument from novelty is "foo is new and different, therefore
it's better". The fallacy of tradition is "foo is the way we've always done
things, therefore it's better".

Neither is the argument I'm making. The argument I'm making is that
because it's likely there are better ways of doing things than the way
we're doing things now (ie, "though foo is the way we've always done
things, there probably exists some bar that is better than foo"), we
should look at new ways of doing things in the hopes that we'll find one
of them that's better that we can then incorporate into our traditions.

That's not a "let's replace Ian, Manoj or Anthony and everything will be
better" -- which without any particular person being selected to do so
would be an appeal to novelty; it's a process change to make it easy for
the technical committee to try new things with the aim of finding better
ways of doing things, and assumes that you trust that the committee
won't stick with new ideas that are worse than traditional ideas, and
that the DPL will tend to select new people whose ideas have a history
of being better than purely random selection.

>  Why is no one responding to the fact that the last ingestion of
>  new blood did not solve the problems?  

It didn't solve the problems; but it did reduce them. According to the
tech-ctte page, 60% of the ctte's decisions have been made in the since
Andi, Steve and I joined which represents about 25% of the ctte's life...
Like I've said earlier, that doesn't count issues that have been punted
one way or another, though my impression is there's been an improvement
there too. I don't believe there's been a single instance of the ctte
deciding that an issue brought to them is entirely out of their remit
in the past few years, in particular.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Technical committee resolution

[Anthony Towns]

On Thu, Mar 13, 2008 at 09:12:54AM -0500, Manoj Srivastava wrote:
> Redoing the new blood thing once again is unlikely to  have much
>  of an effect, really. I think we need to find some of the root causes
>  of the malaise that affects this institution, and fix that, rather
>  than rampaging around rearranging things randomly like a bull in a china
>  shop.

What do you believe these "root causes" are?

Why do you think that structural to increase both external accountability
will have no positivie effect?

Why do you think that turnover within the committee, and the flexibility
that brings both in regards to any personality disputes there may be, or
any ingrained bad practices there may be, will have no positive effect?

Given introducing new blood has already had positive effect, why do
you believe it is unlikely more new blood will have any significant
positive effect?

Why do you think having two new members a year appointed by the DPL is
"rampaging around like a bull in a china shop"?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Technical committee resolution

[Anthony Towns]

On Thu, Mar 13, 2008 at 08:25:40AM -0500, Manoj Srivastava wrote:
> On Thu, 13 Mar 2008 14:37:46 +1000, Anthony Towns said: 
> > On Tue, Mar 11, 2008 at 06:54:50PM +, Ian Jackson wrote:
> >> And, just to make things personal, I submit that one of the problems
> >> is AJ.
> > Because, of course, making things personal is definitely what the
> > technical committee is all about, and just generally a brilliant
> > approach to solving problems.
> And yet,  further down, you respond in kind.[0]

Responding in kind to a personal attack, who would ever have thought?

Do you agree that making things personal is a bad thing? If so, why aren't
you bothered by the concept of only ever removing the worst person on
the committee to replace them with someone better -- and in particular
the rather personal analysis that's required to work out who's the worst
person on the committee?

> > I don't think the committee would be worse off without you; and I find
> > it fundamentally disturbing that any of the founding members are still
> > members ten years later. The same's true of Manoj (though I'm not sure
> > if he joined when the committee was formed, or shortly after
> > that). Even ftpmaster has changed significantly more than that over
> > the same time period, for example.
> This I don't understand.  This seems like a blend of appeal to
>  novelty and a personal vendetta; 

It's never a good idea to make assumptions about things you don't
understand, especially if the only things you can think of are "personal
vendetta".

Any group that relies on volunteers needs to accept they're going to
generally have to work with the people who've got time, which is very
rarely the best people for the job. If you don't have structures in place
to ensure that you can keep moving with a less than ideal set of people,
you're screwed.

> > The reason I didn't raise this last year was because the only
> > reasonable path to removing members seems to me to be oldest first,
> > and I was pretty sure you'd take that personally; given you're
> > decision to hijack dpkg over coding style preferences, I find I'm not
> > so bothered by what you think anymore.
> Actually, basing removal on term of service seems to be the
>  least logical of the replacement strategies;  since it care anught for
>  performance, or value of the contribution, 

That's a feature, not a bug: it avoids making removing someone from the
ctte have to be viewed as a personal attack.

Relying on someone voluntarily removing themselves also avoids that,
but comes at the cost of putting their personal opinion about their
contribution above that of the project.

Being invited to be a member of the ctte should be a result of
exceptional service to the project. And for additional members, it
is. But for continuing members, it's simply a result of having been
there the previous year and not having been controversial enough to
inspire someone else on the ctte to propose a vote for your removal.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Technical committee resolution

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> Neither is the argument I'm making. The argument I'm making is that
> because it's likely there are better ways of doing things than the way
> we're doing things now (ie, "though foo is the way we've always done
> things, there probably exists some bar that is better than foo"), we
> should look at new ways of doing things in the hopes that we'll find one
> of them that's better that we can then incorporate into our traditions.

One of the amazing things about humans that distinguishes them from, say,
lumps of rock is that humans are capable of learning and exploring new
ideas and trying new things.  Hence, it turns out that a group of people
can look at new ways of doing things without changing the people.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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