|
Home > Archive > Debian Developers > July 2004 > Description of tasks (was: -= PROPOSAL =- Release sarge with amd64)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Description of tasks (was: -= PROPOSAL =- Release sarge with amd64)
|
|
| martin f krafft 2004-07-14, 7:51 am |
| also sprach Eduard Bloch <blade@debian.org> [2004.07.13.2140 +0200]:
> Martin, please take appropriate actions. If they say that somebody
> is not skilled enough for the job, do not believe in such a lame
> excuse. (I would also become indispensable if I had never
> documented my work).
We just discussed this stuff on #d-d yesterday and one thing that
popped to my mind is that it's not easy to replace an officer (or
someone with a role) just like that. Disappointing someone makes no
sense without a replacement. The problem I see is twofold: on the
one hand, a lot of people XXXXX and whine, but very few are actually
willing to step up and take responsibility. And even if someone
would like to apply for a role position, s/he is going to have
a real hard time to judge the extent of the commitment required
because the jobs are sparsely (if at all) documented.
As an example, we were (hypothetically) discussing Manoj's exit from
the project, and I would become secretary. Let's furthermore assume
that I would be willing to be secretary and am responsible enough
and give my best, then my decision to apply for secretary is still
unfounded because I never read a "job description" and thus do not
know how much time/effort/skill is required. Plus, once I would have
replaced Manoj (let's assume against his will), I'd have to learn
all the facets of the job, probably without his assistance. And that
would take a while and I'd potentially harm the project until I get
up to speed.
My point is that I think there should be documents describing the
role positions and their exact extents. Moreover, the keepers of
role positions should be persuaded to extend these job descriptions
with all kinds of resources they have accumulated during their
terms. Such a document must be able to convey the extent of the job
and allow someone with enthusiasm and time to get up to speed in
short time.
Only with such document will Debian have a true democracy. Up till
then, it's closer to a meritocracy (I had to look that up) because
those with roles have built up inertia and can only be replaced with
great difficulties. And in case of an accident, the position may be
very difficult to take over, potentially causing serious harm.
I'd appreciate comments, but hope that you, Martin, agrees, and that
you can get your officers to give it a whirl.
Cheers,
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Ingo Juergensmann 2004-07-14, 7:51 am |
| On Wed, Jul 14, 2004 at 11:29:06AM +0200, martin f krafft wrote:
> We just discussed this stuff on #d-d yesterday and one thing that
> popped to my mind is that it's not easy to replace an officer (or
> someone with a role) just like that. Disappointing someone makes no
> sense without a replacement. The problem I see is twofold: on the
> one hand, a lot of people XXXXX and whine, but very few are actually
> willing to step up and take responsibility. And even if someone
> would like to apply for a role position, s/he is going to have
> a real hard time to judge the extent of the commitment required
> because the jobs are sparsely (if at all) documented.
And: current officers tend to not let other people in to do their work.
If those make a secret out of their job, it's really unlikely that others
can take over their jobs - and thus making it easy to argue: "hey, there's
simply noone else that can make my job!"
Let me use an old example (just as an example, not as a base for a new
discussion):
Administrating a buildd is surely somewhat that sounds complex and difficult
to many people. Setting up a buildd and all the stuff is not something that
average Joe User can do.
But that doesn't mean that other people can't learn how to do this.
When I started with my m68k buildd, even some porters didn't really know how
to setup a buildd. We had to ask Roman Hodek for details. But we (i.e. m68k
porters) have learned and shared that knowledge, which led to a broad number
of m68k buildd admins, giving a redundancy not only in buildd machines but
as well in buildd admins.
Some other ports decided to go a different way and to act with single buildd
admins. There are known problems with this.
Conclusion:
Either you can share your knowledge and broaden your workload to many
shoulders or you can act on your own and make a secret out of your business
and a single point of failure out of yourself.
> As an example, we were (hypothetically) discussing Manoj's exit from
> the project, and I would become secretary. Let's furthermore assume
> that I would be willing to be secretary and am responsible enough
> and give my best, then my decision to apply for secretary is still
> unfounded because I never read a "job description" and thus do not
> know how much time/effort/skill is required. Plus, once I would have
> replaced Manoj (let's assume against his will), I'd have to learn
> all the facets of the job, probably without his assistance. And that
> would take a while and I'd potentially harm the project until I get
> up to speed.
And you could harm the project when you're loaded with real life work, so
you can't do your Debian work as much as you should do.
> My point is that I think there should be documents describing the
> role positions and their exact extents. Moreover, the keepers of
> role positions should be persuaded to extend these job descriptions
> with all kinds of resources they have accumulated during their
> terms. Such a document must be able to convey the extent of the job
> and allow someone with enthusiasm and time to get up to speed in
> short time.
And not only job/task descriptions! There has to be manuals describing
regular problems and how to solve them!
Or do you (as a system administrator) go on holiday without leaving
instructions how to deal with problems that might occur?
> Only with such document will Debian have a true democracy. Up till
> then, it's closer to a meritocracy (I had to look that up) because
> those with roles have built up inertia and can only be replaced with
> great difficulties. And in case of an accident, the position may be
> very difficult to take over, potentially causing serious harm.
Yeah, an accident can happen to everyone. What is the emergency plan, when
something like that would happen to some important role persons in Debian?
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-07-14, 5:56 pm |
| On Wed, Jul 14, 2004 at 11:29:06AM +0200, martin f krafft wrote:
> Only with such document will Debian have a true democracy. Up till
> then, it's closer to a meritocracy (I had to look that up) because
> those with roles have built up inertia and can only be replaced with
> great difficulties. And in case of an accident, the position may be
> very difficult to take over, potentially causing serious harm.
So opaque processes are our only defense against a democracy?
I guess I'll have to re-think my support for transparency in Debian.
--
Steve Langasek
postmodern programmer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-07-15, 2:51 am |
| martin f krafft wrote:
<snip>
> My point is that I think there should be documents describing the
> role positions and their exact extents. Moreover, the keepers of
> role positions should be persuaded to extend these job descriptions
> with all kinds of resources they have accumulated during their
> terms. Such a document must be able to convey the extent of the job
> and allow someone with enthusiasm and time to get up to speed in
> short time.
> Only with such document will Debian have a true democracy.
.....or, indeed, a true meritocracy. See below.
> Up till
> then, it's closer to a meritocracy (I had to look that up)
Except it isn't. In a meritocracy, a new person who's more competent (for
whatever reason -- perhaps because the old person was tired or busy) would
take over quickly. This does *not* happen.
It's more like a quangocracy (rule of quasi-autonomous non-governmental
organizations) or a squattocracy (rule by squatters). The people who are
in certain positions are there because they are there, more than for any
other reason.
> because
> those with roles have built up inertia and can only be replaced with
> great difficulties.
Precisely.
> And in case of an accident, the position may be
> very difficult to take over, potentially causing serious harm.
Furthermore, with a more specified role description, it becomes possible to
objectively evaluate alternative volunteers for the roles -- or indeed, to
break up the roles into smaller subroles. Right now both actions appear to
be impossible.
> I'd appreciate comments, but hope that you, Martin, agrees, and that
> you can get your officers to give it a whirl.
Good luck.
--
There are none so blind as those who will not see.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-07-15, 2:51 am |
| On Thu, Jul 15, 2004 at 01:24:41AM -0400, Nathanael Nerode wrote:
> martin f krafft wrote:
> <snip>
[vbcol=seagreen]
> ....or, indeed, a true meritocracy. See below.
> Except it isn't. In a meritocracy, a new person who's more competent (for
> whatever reason -- perhaps because the old person was tired or busy) would
> take over quickly. This does *not* happen.
> It's more like a quangocracy (rule of quasi-autonomous non-governmental
> organizations) or a squattocracy (rule by squatters). The people who are
> in certain positions are there because they are there, more than for any
> other reason.
So you speak with such authority, surely this means *you've* approached
the mirror team personally, offered your assistance, and been turned
down?
--
Steve Langasek
postmodern programmer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-07-15, 7:51 am |
| Steve Langasek wrote:
> On Thu, Jul 15, 2004 at 01:24:41AM -0400, Nathanael Nerode wrote:
>
>
>
>
>
> So you speak with such authority, surely this means *you've* approached
> the mirror team personally, offered your assistance, and been turned
> down?
The mirror team? So it's the mirror team who needs help now? I hadn't
heard of any issues with the mirror team. (And I certainly wasn't
referring to them.) What do they need help with?
--
There are none so blind as those who will not see.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr - Debian Project Leader 2004-07-16, 7:51 am |
| * martin f krafft <madduck@debian.org> [2004-07-14 11:29]:
> And even if someone would like to apply for a role position, s/he is
> going to have a real hard time to judge the extent of the commitment
> required because the jobs are sparsely (if at all) documented.
> My point is that I think there should be documents describing the
> role positions and their exact extents. [...] Such a document must
> be able to convey the extent of the job and allow someone with
> enthusiasm and time to get up to speed in short time.
I fully agree that we need better documentation outlining the roles of
our delegates (and other functions [*]), the tasks they perform
exactly and how they are being performed. This will increase
transparency, hopefully attract more volunteers and probably increase
the burden on the people performing roles since other people would
understand their tasks better (for example, I reckon that a document
explaining what is being done during NEW processing would decrease the
number of packages that have to be rejected because maintainers could
use that document as a checklist for their packages before uploading).
The question of more documentation also came up during the DPL debates
and I'm certainly committed to working on this. At the same time,
people have to understand that (in the short run) documenting the
procedures will take away time from the delegates which they could
spend on performing their tasks. Thinking about this issue during the
last few days, I have decided to appoint a specific delegate who will
work with our delegates to work on this documentation. This will
ensure that the documentation will get done and that the delegates'
roles are still being performed. More on that soon on d-d-announce.
[*] I don't think this is limited to delegates. There are many other
areas in the project which need better documentation. I've seen a
growing number of packages include debian/README.NMU files to document
important knowledge which is useful for non-maintainers of a package
performing an upload. I think it's important to document your own
packaging procedures so other people can follow them when they help
out with your package. For one of my packages, I have a fairly
detailed README file in SVN documenting how new releases are being
made. I can only encourage other maintainers to do the same.
--
Martin Michlmayr
leader@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr 2004-07-16, 7:51 am |
| * Ingo Juergensmann <ij@2004.bluespice.org> [2004-07-14 12:04]:
> Let me use an old example (just as an example, not as a base for a new
> discussion):
> Administrating a buildd is surely somewhat that sounds complex and difficult
> to many people. Setting up a buildd and all the stuff is not something that
> average Joe User can do.
> But that doesn't mean that other people can't learn how to do this.
> When I started with my m68k buildd, even some porters didn't really know how
> to setup a buildd. We had to ask Roman Hodek for details. But we (i.e. m68k
> porters) have learned and shared that knowledge, which led to a broad number
> of m68k buildd admins, giving a redundancy not only in buildd machines but
> as well in buildd admins.
I've never tried to set up a buildd (only sbuild) but I've heard
before that it's fairly complex and hardly documented. Since you have
obtained the knowledge and insights about setting up a buildd, have
you documented this to make the knowledge available to everyone? Or
is this a shared secret only passed along within the m68k cabal?
--
Martin Michlmayr
tbm@cyrius.com
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr - Debian Project Leader 2004-07-16, 7:52 am |
| * Ingo Juergensmann <ij@2004.bluespice.org> [2004-07-16 14:27]:
> As DPL: when you believe that there is need of a buildd
> documentation you shall have the power to delegate this task to some
> of your people. Or just wait for a volunteer...
OK, so are you going to document it? (Or are you just going to
respond with "I'm not a Debian developer so the DPL cannot ask me to
do work".)
> Remember: I learned my lesson that Debian is done by volunteers and
> nobody can force me to do anything. :-)
Yes, but our community also ignores people who only complain and don't
contribute. Asking other people to create documentation is a little
bit hypocritical when you're not willing to do the same.
--
Martin Michlmayr
leader@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr 2004-07-16, 7:52 am |
| * Ingo Juergensmann <ij@2004.bluespice.org> [2004-07-16 14:42]:
> I won't document wanna-build/buildd/sbuild, because I'm not a buildd
> admin
You won't or you cannot?
Anyway, I think it is pretty obvious by now to anyone following this
list that you're not really interested in contributing.
--
Martin Michlmayr
tbm@cyrius.com
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matthew Palmer 2004-07-16, 7:52 am |
| On Fri, Jul 16, 2004 at 02:42:06PM +0200, Ingo Juergensmann wrote:
> Martin Michlmayr - Debian Project Leader said:
>
> Well, to stress always the volunteer-effekt is a little bit strange as
> well, when you want get things done, isn't it? ;)
You must be the change you wish to see in the world.
- Matt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Simon Huggins 2004-07-16, 5:54 pm |
| Salut Josselin!
On Fri, Jul 16, 2004 at 03:03:23PM +0200, Josselin Mouette wrote:
> Le ven, 16/07/2004 à 13:51 +0100, Martin Michlmayr a écrit :
> Oh, sure. Setting up buildd.net was not a contribution. That's probably
> why I have to go there several times a week to find out information
> that's not on buildd.debian.org.
What sort of information is on buildd.net and not on buildd.debian.org?
Did you see Igloo's post somewhere in this thread?
--
Simon Huggins \ Cows turn themselves inside out all the time. - Officer,
\ South Park
http://www.earth.li/~huggie/ htag.pl 0.0.22
| |
| Ingo Juergensmann 2004-07-16, 5:54 pm |
| On Fri, Jul 16, 2004 at 01:51:38PM +0100, Martin Michlmayr wrote:
> * Ingo Juergensmann <ij@2004.bluespice.org> [2004-07-16 14:42]:
> You won't or you cannot?
> Anyway, I think it is pretty obvious by now to anyone following this
> list that you're not really interested in contributing.
Oh, when you are saying this, it must be true. The DPL is always right, Sir!
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2004-07-16, 5:54 pm |
| On Fri, Jul 16, 2004 at 07:22:17PM +0200, Ingo Juergensmann wrote:
> On Fri, Jul 16, 2004 at 01:51:38PM +0100, Martin Michlmayr wrote:
>
> Oh, when you are saying this, it must be true. The DPL is always
> right, Sir!
And you're still convinced that it's the FTPmaster team that has
problems communicating?
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-07-16, 5:54 pm |
| On Fri, Jul 16, 2004 at 08:51:45PM +0200, Ingo Juergensmann wrote:
> David Weinehall said:
[vbcol=seagreen]
> Yup! :-)
<plonk>
--
Steve Langasek
postmodern programmer
| |
| Wouter Verhelst 2004-07-16, 5:54 pm |
| On Fri, Jul 16, 2004 at 10:54:03AM -0700, Adam McKenna wrote:
> On Fri, Jul 16, 2004 at 01:35:13PM +0100, Martin Michlmayr - Debian Project Leader wrote:
>
> No, it isn't. I may not be a good writer. I may not have time. There are
> many valid reasons I might request something
Absolutely true. However...
> which I'm either unwilling or unable to do myself.
...Asking someone else to do something you're unable to do yourself, I
can understand. But there's a major difference between "unable" and "not
willing".
> Pointing out work that needs to be done is not hypocrisy. I'm
> surprised to hear this coming from the DPL.
>
> If you disagree with this, then perhaps we should remove the RFP
> functionality from WNPP.
an RFP is useful when you can't do it because of lack of skills, time,
or whatnot. It is not useful when you simply don't /want/ to do it.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
| |
| Matthias Urlichs 2004-07-17, 5:53 pm |
| Hi, Martin Michlmayr wrote:
> I've never tried to set up a buildd (only sbuild) but I've heard
> before that it's fairly complex and hardly documented.
Speaking as somebody who has set up his very own little multi-arch
buildd/sbuild/wannabuild empire in the basement, I can attest that it's
not a task suitable for a beginner. On the other hand, it's definitely
possible.
Let's face it, the existing buildd setup does have a few problems (it
wastes CPU time, wastes bandwidth, and wastes admin time), and multibuild
is designed to solve them. I only hope that, when it's ready, people will
examine the code on its own merits.
Unfortunately, if the current flameage is any indication, I'm not going to
hold my breath. :-(
--
Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matthew Palmer 2004-07-18, 2:48 am |
| On Fri, Jul 16, 2004 at 03:03:23PM +0200, Josselin Mouette wrote:
> Le ven, 16/07/2004 ? 13:51 +0100, Martin Michlmayr a ?crit :
>
> Oh, sure. Setting up buildd.net was not a contribution. That's probably
> why I have to go there several times a week to find out information
> that's not on buildd.debian.org.
Would s/contributing\./contributing in a fashion substantively differently
from the fashion he is accusing ftpmaster of contributing./ be more
appropriate?
I actually prefer ftpmaster's actions to Ingo's -- it's a rather useful
demonstration of the famous saying "It is better to remain silent and be
thought a fool than to open one's mouth and remove all doubt".
- Matt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|