|
Home > Archive > Debian Developers > August 2005 > Dogme05: Team Maintenance
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 |
Dogme05: Team Maintenance
|
|
| W. Borgert 2005-08-14, 5:56 pm |
| Hi,
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams. A fine way to do this, is by
having a pkg- project at alioth.debian.org. It is useful to
invite non-DDs, esp. upstream developers and people from Debian
derivatives to participate in such teams.
Assumptions:
I. The most important packages in Debian are maintained by
teams. The experience with that modus operandi is very good.
II. Team maintainance gives higher quality packages, as more
people look at the packaging details.
III. The responsiveness on bug reports is higher, as more people
can react without having to NMU. Adjustments between team
members can slow down this, but this is just a matter of
agreements inside the team.
IV. Less need to orphan packages, as most teams will not
collapse, if a single maintainer drops out. Less work for
our lion-hearted QA team.
V. If not at least two maintainers can be found for a particular
package, it is not worthwhile to have it in Debian, at least
not in a release. experimental is OK.
VI. The advantages of team maintenance outweigh the problem of
team maintenance overhead.
VII. Team maintainence helps us to collaborate with upstream
and derivers.
VIII. Packages not maintained by teams are not to go into
unstable/testing/stable.
IX. As alioth becomes even more important to Debian, we will
have to strengthen (HA-ing) this resource.
X. Teams shall meet online or in sauna. They are allowed to do
DDR or ballroom dancing.
[Dogme05 is, of course, a pun on Dogme95.]
Cheers,
--
Wolfgang Borgert <debacle@debian.org>, http://people.debian.org/~debacle/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Jaspert 2005-08-14, 5:56 pm |
| | |
| Ben Armstrong 2005-08-14, 8:49 pm |
| On Sun, 2005-08-14 at 14:15 +0000, W. Borgert wrote:
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.
It's a nice ideal.
> It is useful to
> invite non-DDs, esp. upstream developers and people from Debian
> derivatives to participate in such teams.
I've tried that. No luck yet.
> Assumptions:
No arguments against I through IV.
> V. If not at least two maintainers can be found for a particular
> package, it is not worthwhile to have it in Debian, at least
> not in a release. experimental is OK.
Says who? I maintain some packages like this. Let's say I support 50
to 100 niche users for a given package, but I'm the only developer in
the user community who cares to maintain the package in Debian. I
maintain the package well, and my users are happy. I would not be at
all happy if my package were forced out of Debian because it's "not
worthwhile". I think that would be a terrible injustice to my users.
> VI. The advantages of team maintenance outweigh the problem of
> team maintenance overhead.
In my case, there would be a team of one. I could take a "build it and
they will come" approach, I suppose, but unless by creating the project
actually attracted other developers, the team maintenance overhead
(basically just startup costs) would outweigh the advantages. Let's
just say I'm not overly optimistic about my prospects, given my failure
so far to attract another developer to co-maintain with me. Upstream is
just too busy doing upstream work, and doesn't want to be bothered with
packaging, which I seem to do well enough without their help.
> VII. Team maintainence helps us to collaborate with upstream
> and derivers.
I collaborate just fine with upstream. However, this collaboration with
derviers sounds interesting. I haven't yet spoken with any derivers
responsible for my packages. That might be an overlooked source of help
for me. Thanks for the reminder that they're out there.
> VIII. Packages not maintained by teams are not to go into
> unstable/testing/stable.
Again: will a team of one, with a "help wanted" sign hanging on it
suffice? I am ideologically supportive of team maintenance, but
pessimistic about the prospects of some useful packages ever having more
than one maintainer, because they serve a small subgroup of specialized
users within Debian.
> IX. As alioth becomes even more important to Debian, we will
> have to strengthen (HA-ing) this resource.
"HA-ing". I'm sorry. I don't know what you mean.
> X. Teams shall meet online or in sauna. They are allowed to do
> DDR or ballroom dancing.
Works for me.
Ben
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Goerzen 2005-08-15, 2:49 am |
| On Sun, Aug 14, 2005 at 02:15:43PM +0000, W. Borgert wrote:
> Hi,
>
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams. A fine way to do this, is by
> having a pkg- project at alioth.debian.org. It is useful to
> invite non-DDs, esp. upstream developers and people from Debian
> derivatives to participate in such teams.
I think the goal is good, but the implementation is not.
Why not rather move towards a more BSD approach, where any developer
can commit changes to any package? It would work around having the
awkwardness of finding members of a team, or alternately, having to
convince someone to let you join a particular team.
What's more, alioth takes a lot of time to work with. I often do
development on machines that are not connected to the 'net at a given
time, and upload packages later. I would have no problem hosting my
darcs repository on alioth, but I would have a problem having to go to
alioth every time I upload a new version, or every time I upload a new
package, or whatnot. If it can be integrated in a sane fashion with
other parts of Debian, then fine. Otherwise, if it costs me time, I
want nothing to do with it. Time I spend mucking around on alioth is
time I'm not spending fixing bugs or adding features.
-- John
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-08-15, 2:49 am |
| On Aug 15, John Goerzen <jgoerzen@complete.org> wrote:
> Why not rather move towards a more BSD approach, where any developer
> can commit changes to any package? It would work around having the
Any developer can already "commit" changes to any package. The obvious
problem is that it is very hard to have everybody involved agree on
non-trivial changes.
But I think that encouraging NMUs (even mass-NMUs) for trivial changes
would be good.
--
ciao,
Marco
| |
| Roberto C. Sanchez 2005-08-15, 2:49 am |
| On Mon, Aug 15, 2005 at 05:08:00AM +0200, Marco d'Itri wrote:
> On Aug 15, John Goerzen <jgoerzen@complete.org> wrote:
>
> Any developer can already "commit" changes to any package. The obvious
> problem is that it is very hard to have everybody involved agree on
> non-trivial changes.
> But I think that encouraging NMUs (even mass-NMUs) for trivial changes
> would be good.
>
I tend to agree. Personally, I keep all my packages under subversion.
While I would certainly welcome help if I started falling behind or
otherwise needed it, it would be rather disruptive if someone started
uploading updates to my packages without coordination.
Regardless of whether or not I agreed with the changes, there is a real
problem in the sense that my package under revision control is no longer
in sync with whatever is in the archive. I know that NMUs also pose the
same problem, but one of the goals behind an NMU should be to upload the
*minimal* change that corrects the specific problem. In such cases it
should not be too difficult to get back in sync.
There would either have to be a) some agreed upon central repository for
*all* packages, or b) coordination between the primary team or
maintainer. Option b is essentially what we do now, just that the
coordination is typically done in the form of patches. I.e., people
don't go around randomly uploading other people's packages. Option a is
likely doomed to fail since revision control tool choices are like a
choice of text editor or religion.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
| |
| Adam Heath 2005-08-15, 2:49 am |
| On Sun, 14 Aug 2005, Roberto C. Sanchez wrote:
> Regardless of whether or not I agreed with the changes, there is a real
> problem in the sense that my package under revision control is no longer
> in sync with whatever is in the archive. I know that NMUs also pose the
> same problem, but one of the goals behind an NMU should be to upload the
> *minimal* change that corrects the specific problem. In such cases it
> should not be too difficult to get back in sync.
Actually, this brings up an interesting point.
When a new source gets uploaded, it replaces the previous. If several NMUs
occur, each one replaces the former. So, when the real maintainer(s) wake up,
they can only see the most recent NMU that took place.
It'd be nice if NMUs source uploads were auto-archived.
Of course, this would be solved by the idea that people have thrown around:
checking every source upload into revision control.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| W. Borgert 2005-08-15, 2:49 am |
| On Sun, Aug 14, 2005 at 08:29:47PM -0300, Ben Armstrong wrote:
> Says who? I maintain some packages like this. Let's say I support 50
> to 100 niche users for a given package, but I'm the only developer in
> the user community who cares to maintain the package in Debian. I
> maintain the package well, and my users are happy. I would not be at
> all happy if my package were forced out of Debian because it's "not
> worthwhile". I think that would be a terrible injustice to my users.
Some of the things under Dogme05 is certainly exaggeration.
Sorry, if people thought I want to propose enforcement of "team
maintenance policy". However, team maintenance for all
essential and standard is worthwhile and not un-realistic.
> "HA-ing". I'm sorry. I don't know what you mean.
Sorry, we may have to many abbreviation based verbs already, so
I should not invent new ones: HA = high availability.
Cheers,
--
W. Borgert <debacle@debian.org>, http://people.debian.org/~debacle/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stig Sandbeck Mathisen 2005-08-15, 2:49 am |
| "W. Borgert" <debacle@debian.org> writes:
> Sorry, if people thought I want to propose enforcement of "team
> maintenance policy". However, team maintenance for all essential
> and standard is worthwhile and not un-realistic.
It's a good idea to discuss it, unless it's been discussed to death
already.
--
Stig Sandbeck Mathisen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul TBBle Hampson 2005-08-15, 7:49 am |
| On Mon, Aug 15, 2005 at 12:16:24AM -0500, Adam Heath wrote:
> When a new source gets uploaded, it replaces the previous. If several NMUs
> occur, each one replaces the former. So, when the real maintainer(s) wake up,
> they can only see the most recent NMU that took place.
Only if each NMU does not build upon the previous _and_ each NMU
fails to follow NMU guidelines and submit a bug with the complete
NMU diff to the BTS.
Which is why we have those guidelines. ^_^
(I'm not saying this doesn't happen, but it's as bad as a broken
source upload, give or take.)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
| |
| Jon Dowland 2005-08-15, 7:49 am |
| On Sun, Aug 14, 2005 at 02:15:43PM +0000, W. Borgert wrote:
> Assumptions:
> III. The responsiveness on bug reports is higher, as more people
> can react without having to NMU. Adjustments between team
> members can slow down this, but this is just a matter of
> agreements inside the team.
I do not agree that this is always the case. I think that sometimes, a
bug which doesn't look like fun to debug or fix can be passed over in
team maintenance situations, as no one person is responsible for the
package (oh, someone else in the team will pick this one up...)
--
Jon Dowland http://jon.dowland.name/
FD35 0B0A C6DD 5D91 DB7A 83D1 168B 4E71 7032 F238
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ben Armstrong 2005-08-15, 5:54 pm |
| On Mon, 2005-08-15 at 06:14 +0000, W. Borgert wrote:
> Some of the things under Dogme05 is certainly exaggeration.
> Sorry, if people thought I want to propose enforcement of "team
> maintenance policy". However, team maintenance for all
> essential and standard is worthwhile and not un-realistic.
Well, you did say "all packages". If you had talked explicitly only
about essential and standard packages, you would have heard no
complaints from me.
>
> Sorry, we may have to many abbreviation based verbs already, so
> I should not invent new ones: HA = high availability.
Thanks for the secret TLA decoder ring.
Ben
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam Heath 2005-08-15, 8:49 pm |
| On Mon, 15 Aug 2005, Paul TBBle Hampson wrote:
> On Mon, Aug 15, 2005 at 12:16:24AM -0500, Adam Heath wrote:
>
> Only if each NMU does not build upon the previous _and_ each NMU
> fails to follow NMU guidelines and submit a bug with the complete
> NMU diff to the BTS.
The bts is the only way this occurrs.
Several maintainers now maintain their packages completely within version
control. I can see them wanting to have every version ever uploaded as a
separate tag/branch(whatever).
If an NMU upload does not file a bug, then this becomes problematic.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alexander Schmehl 2005-08-16, 7:51 am |
| Dear Wolfang,
* W. Borgert <debacle@debian.org> [050814 16:15]:
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams. [..]
Do you realy think you can enforce teamwork? I don't think so. Either
some people will work together as a team or individuals will do it their
own way. And I don't think it will be a good idea, to force those
individuals to work in a team.
Yours sincerely,
Alexander
--
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html
| |
| Petter Reinholdtsen 2005-08-16, 7:51 am |
| [Alexander Schmehl]
> Do you realy think you can enforce teamwork? I don't think so.
> Either some people will work together as a team or individuals will
> do it their own way. And I don't think it will be a good idea, to
> force those individuals to work in a team.
I agree. There will always be people unwilling or incapable of
working in teams, and some of them will be debian developers. I
wounder how many of these decided to join in on this thread.
But I believe it is a good idea to remove the most important packages
in debian from the single set of hands maintaining them at the moment,
if the current maintainer is unwilling to maintain these in a team.
They should maintain less important packages or learn how to maintain
them in a team.
We should strive to increase what I normally call the bus-factor; how
many people need to be run over by a bus before the project stops.
And for several of the packages in debian, the count is 1 or less. I
believe we should at least aim for a factor at two or above, to be
able to cope with accidents, burnouts and other issues affecting
people from time to time.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote:
> [Alexander Schmehl]
>
> I agree. There will always be people unwilling or incapable of
> working in teams, and some of them will be debian developers. I
> wounder how many of these decided to join in on this thread.
>
> But I believe it is a good idea to remove the most important packages
> in debian from the single set of hands maintaining them at the moment,
> if the current maintainer is unwilling to maintain these in a team.
I disagree. If the maintainer is doing a good job on his (or her) own,
then there is no need at all to take away their packages.
[...]
> We should strive to increase what I normally call the bus-factor; how
> many people need to be run over by a bus before the project stops.
> And for several of the packages in debian, the count is 1 or less.
That's not true. For several of the packages in Debian, it is true that
there will be a problem if their maintainer will be run over by a bus.
However, that in no way means the project "stops". As the past has
taught us, should something like that happen, there will be people
willing to take over. It might take a bit longer for the new maintainer
to be up to speed as compared to when one member of a team gets run over
by a bus, but that doesn't mean "the project stops".
We should strive to increase the quality in Debian. If some people can
produce higher-quality packages by working in a team, then more power to
them. If other people can produce higher-quality packages by /not/
working in a team, then there is no reason to force them to work in a
team.
Don't forget that every bit of teamwork results in some overhead; you
have to communicate to your team members what you're doing, and all of
your team members have to understand it (which may involve tedious
explanations and/or some learning time for your team members). Depending
on the complexity of a package and the amount of work required to
maintain it, this overhead may just not be worth it.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
| |
| Steinar H. Gunderson 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 10:08:15AM -0400, Roberto C. Sanchez wrote:
> OK. Please identify the most important packages in Debian :-)
> Hint: this is not easy. There would need to be some sort of metric or
> heuristic for deciding the "importance" of a package.
We already have a Priority: field.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote:
> [Alexander Schmehl]
>
> I agree. There will always be people unwilling or incapable of
> working in teams, and some of them will be debian developers. I
> wounder how many of these decided to join in on this thread.
>
> But I believe it is a good idea to remove the most important packages
> in debian from the single set of hands maintaining them at the moment,
> if the current maintainer is unwilling to maintain these in a team.
> They should maintain less important packages or learn how to maintain
> them in a team.
>
OK. Please identify the most important packages in Debian :-)
Hint: this is not easy. There would need to be some sort of metric or
heuristic for deciding the "importance" of a package.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
| |
| Ben Armstrong 2005-08-16, 6:00 pm |
| On Tue, 2005-08-16 at 15:46 +0200, Wouter Verhelst wrote:
> It might take a bit longer for the new maintainer
> to be up to speed as compared to when one member of a team gets run over
> by a bus, but that doesn't mean "the project stops".
Team maintenance is only one way to accomplish the goal of uninterrupted
high quality of maintenance for all standard & essential packages.
The PTS allows for non-maintainers of an important package to watch
what's happening without necessarily being directly involved in a formal
team. Perhaps we can reduce the time to come up to speed by encouraging
non-team-maintained packages to be "shadowed" by additional developers
who can then be called upon to NMU as needed? This would entail
watching the bug reports as they come in, trying to figure out what's
wrong, contributing additional info and/or patches to the bug reports if
appropriate, and checking new releases to see what the maintainer has
done and why.
I think it's important not to underestimate the possible consequences of
it "taking a bit longer to come up to speed" when a maintainer of an
important package suddenly disappears. For some values of "a bit", the
project could suffer a fair amount through such a loss. I can't readily
provide an anecdote for when this ever occurred, but I do have a vivid
imagination.
Ben
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 11:03:17AM -0300, Ben Armstrong wrote:
> On Tue, 2005-08-16 at 15:46 +0200, Wouter Verhelst wrote:
[...][vbcol=seagreen]
> I think it's important not to underestimate the possible consequences of
> it "taking a bit longer to come up to speed" when a maintainer of an
> important package suddenly disappears. For some values of "a bit", the
> project could suffer a fair amount through such a loss. I can't readily
> provide an anecdote for when this ever occurred, but I do have a vivid
> imagination.
Exactly. I can't, either; and there have been some takeovers of some
pretty serious packages who were maintained by one person in the past.
As an example, consider what happened when Joel Klecker died (who was
maintaining a package of quite some importance at the time).
I'm not saying it's necessarily a bad idea to have team maintenance; on
the contrary. But forcing people to maintain packages in teams is, I
think, a /very/ bad idea. There are some packages that can easily be
maintained by one person alone, even if they're quite important; and
forcing a team upon such a package is just a drain on the time of the
person who's been maintaining it up to then.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florent Bayle 2005-08-16, 6:00 pm |
| | |
| Petter Reinholdtsen 2005-08-16, 6:00 pm |
| [Roberto C. Sanchez]
> OK. Please identify the most important packages in Debian :-) Hint:
> this is not easy. There would need to be some sort of metric or
> heuristic for deciding the "importance" of a package.
I do not see the need for a waterproof definition capable of splitting
the archive in two, the important and the not so important. We could
for example start with the packages in base (aka installed by
debootstrap), and add the most commonly installed packages as reported
by popularity-contest.
I have little doubt that these packages are the most important
packages in debian, and that all of them are more important than for
example one of my own packages, ipmitool. 
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thijs Kinkhorst 2005-08-16, 6:00 pm |
| On Tue, August 16, 2005 15:46, Wouter Verhelst wrote:
>
> That's not true. For several of the packages in Debian, it is true that
> there will be a problem if their maintainer will be run over by a bus.
> However, that in no way means the project "stops". As the past has
> taught us, should something like that happen, there will be people
> willing to take over.
You're missing an important case here: the one where the maintainer isn't
completely absent, but lacks the time to maintain the package in an
optimal manner. There are a lot of valid reasons for this to happen, be it
real-life responsibilities or other tasks within Debian, but it hurts the
quality of the package.
It would not be fair to ditch the maintainer in such a case, but having
more than one adds a lot more continuity to the quality of a package. This
is especially important for packages that are particulary central to
debian, i.e. of high priority. The PTS currently says that "you should
find some co-maintainers" if the package is priority standard or higher; I
would like to see that upgraded that to 'must'.
The argument that a maintainer is currently doing just fine doesn't hold
in my opinion, since being swamped in other areas can happen to anyone,
and can happen unexpectedly when it's too late to get a comaintainer. You
can of course NMU, but that has its problems, and NMU's tend to be only
done for the most pressing issues. A co-maintainer who is familiar with
the package and knows what's going on can do a lot more good than
different people NMUing.
regards,
Thijs
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst wrote:
> On Tue, August 16, 2005 15:46, Wouter Verhelst wrote:
>
> You're missing an important case here: the one where the maintainer isn't
> completely absent, but lacks the time to maintain the package in an
> optimal manner.
Those are excellent reasons to give the package away and/or to start
looking for comaintainers.
[...]
> The argument that a maintainer is currently doing just fine doesn't hold
> in my opinion, since being swamped in other areas can happen to anyone,
> and can happen unexpectedly when it's too late to get a comaintainer.
Uh. I meant to say that there are some packages for which maintenance is
so low-volume and so easy that the overhead imposed by team-maintenance
is just not worth it.
For low-volume, easy-to-maintain packages, it's never too late to go get
a comaintainer. Or to give the package away. And I simply don't believe
that 'important package' implies 'lots of work to maintain it'.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
| |
| Ben Armstrong 2005-08-16, 6:00 pm |
| On Tue, 2005-08-16 at 16:42 +0200, Wouter Verhelst wrote:
> For low-volume, easy-to-maintain packages, it's never too late to go get
> a comaintainer. Or to give the package away. And I simply don't believe
> that 'important package' implies 'lots of work to maintain it'.
I think what you're saying here is quite reasonable. A simple concrete
example might help to make this point. Pick a specific package that
meets these criteria and go through the thought exercise of when the
maintainer is run over by a bus and the package has no co-maintainer. I
think the problem is, many of us, like me, do have vivid imaginations
and envision "bad things" happening when an "important" package loses
its only maintainer because the problem is painted in strokes that are
overly broad. Perhaps I was too indirect in my request for anecdotes.
I'd like some more specific packages discussed so we can identify where
the potential problems lie and focus our energies on those, rather than
worrying over all of the corner cases that aren't real problems.
Ben
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alexander Schmehl 2005-08-16, 6:00 pm |
| Hi!
* Florent Bayle <florent.bayle@free.fr> [050816 16:20]:
> And why not also using popularity-contest (eg. if a package is used by more
> than X users, it should be maintained by a team).
And what, if a package maintained by a single person (who is doint a
good job) is get's a growing userbase and pops beyong X users? What if
the single maintainer is doing a good job, but lacks the ability to
work in a team? What do you want to do, do solve the inaccuracy of
popcon?
Yes, I agree. "Important" packages should be maintained by a team, by
trying to enforce such a policy will IMHO cause more problems than it
solves.
Yours sincerely,
Alexander
--
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html
| |
| Henning Makholm 2005-08-16, 6:00 pm |
| Scripsit Wouter Verhelst <wouter@debian.org>
> I'm not saying it's necessarily a bad idea to have team maintenance; on
> the contrary. But forcing people to maintain packages in teams is, I
> think, a /very/ bad idea.
Not to mention that people who sincerely believe they work most
efficiently as a one-man team would just start forming pro-forma teams
that officially pooled maintenance of their former packages but and
internally followed a gentleman's agreement about keeping hands off
each other's stuff.
What next? A package cannot be uploaded N times in a row by the same
team member?
--
Henning Makholm "Occam was a medieval old fart. The simplest
explanation that fits the facts is always, God did it."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| W. Borgert 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote:
> Do you realy think you can enforce teamwork? I don't think so. Either
> some people will work together as a team or individuals will do it their
One cannot enforce teamwork. Dogma #10 suggests team meetings
in sauna as encouragement for team building.
> own way. And I don't think it will be a good idea, to force those
> individuals to work in a team.
Debian is a large-scale team. Teamwork is a necessity for all
the 1278(?) of us. Not by force, maybe by sauna.
Cheers,
--
Wolfgang Borgert <debacle@debian.org>, http://people.debian.org/~debacle/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-08-16, 6:00 pm |
| On Tue, Aug 16, 2005 at 09:15:11PM +0000, W. Borgert wrote:
> On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote:
>
> One cannot enforce teamwork. Dogma #10 suggests team meetings
> in sauna as encouragement for team building.
>
Nobody ever told me that Debian had a sauna for team meetings. Do I
need to wait until I am through NM, or can I get access beforehand?
Where is it located :-)
>
> Debian is a large-scale team. Teamwork is a necessity for all
> the 1278(?) of us. Not by force, maybe by sauna.
>
The Debian team is probably much larger than that, since it includes
people reporting bugs, providing patches, and generally helping out.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
| |
| Marc Haber 2005-08-18, 7:50 am |
| On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst
<wouter@debian.org> wrote:
>I disagree. If the maintainer is doing a good job on his (or her) own,
>then there is no need at all to take away their packages.
How do we find out whether a maintainer is doing his/her job well? For
example, are the ifupdown and sysklogd packages well maintained?
Greetings
Marc
--=20
-------------------------------------- !! No courtesy copies, please !! =
-----
Marc Haber | " Questions are the | Mailadresse im =
Header
Mannheim, Germany | Beginning of Wisdom " | =
http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 =
72739834
| |
| Marc Haber 2005-08-18, 7:50 am |
| On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst
<wouter@debian.org> wrote:
>On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst wrote:
isn't[vbcol=seagreen]
>
>Those are excellent reasons to give the package away and/or to start
>looking for comaintainers.
In theory, you are right. In practice, we have more than a couple of
packages in that state with the maintainer flatly refusing to give
away the package or even allow co-maintenance.
Greetings
Marc
--=20
-------------------------------------- !! No courtesy copies, please !! =
-----
Marc Haber | " Questions are the | Mailadresse im =
Header
Mannheim, Germany | Beginning of Wisdom " | =
http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 =
72739834
| |
| Henning Makholm 2005-08-18, 7:50 am |
| Scripsit Marc Haber <mh+debian-devel@zugschlus.de>
> On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst
[vbcol=seagreen]
> In theory, you are right. In practice, we have more than a couple of
> packages in that state with the maintainer flatly refusing to give
> away the package or even allow co-maintenance.
It is already the case that "flatly refusing to give away the package
or even allow co-maintenance" *should* not happen at all and, if it
does happen, *should* not prevent the package from eventually being
given to somebody who is willing to keep it properly maintained.
I agree that our mechanism for turning those "should"s into "do"s are
not, empirically, always working well. But simply adding by fiat
another requirement for the maintainer to flatly refuse to follow is
not likely to help solving the underlying problem.
--=20
Henning Makholm "H=F8r, hvad er det egent=
lig
der ikke kan blive ved med at g=
=E5?"
| |
| Wouter Verhelst 2005-08-18, 7:50 am |
| On Thu, Aug 18, 2005 at 10:33:53AM +0200, Marc Haber wrote:
> On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst
> <wouter@debian.org> wrote:
>
> How do we find out whether a maintainer is doing his/her job well?
'Check if there is consensus that the maintainer is doing his/her job
well'. Somehow. Preferably /not/ through GR.
Anyway, that was not the point; the point was that the status quo is not
so bad that we need to invent yet another bureaucratic procedure that
will not likely improve much.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thaddeus H. Black 2005-08-18, 5:55 pm |
| Henning Makholm wrote:
> Scripsit Marc Haber <mh+debian-devel@zugschlus.de>
>
>
>
> It is already the case that "flatly refusing to give away the package
> or even allow co-maintenance" *should* not happen at all and, if it
> does happen, *should* not prevent the package from eventually being
> given to somebody who is willing to keep it properly maintained.
>
> I agree that our mechanism for turning those "should"s into "do"s are
> not, empirically, always working well. But simply adding by fiat
> another requirement for the maintainer to flatly refuse to follow is
> not likely to help solving the underlying problem.
We have such a mechanism? I didn't know this.
Investigating, one sees some words in Policy 3.3 and Developer's
Reference 7.4 on the topic, but the words do not seem to speak of
intransigent maintainers, only of inactive ones. Verse 6.1.4 in the
Constitution seems arguably to give power to the Technical Committee to
do what you suggest, but if so, the power remains theoretical: it is not
in practice used.
Never having personally encountered a serious problem with an
intransigent maintainer, I do not know much about it, but now you make
me curious. If there are interesting facts I didn't know hereto about
the Project, please elaborate.
| |
| Henning Makholm 2005-08-20, 5:54 pm |
| Scripsit "Thaddeus H. Black" <t@b-tk.org>
> Henning Makholm wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> We have such a mechanism? I didn't know this.
I didn't actually look it up, but even if the only mechanism we have
is "work it out on the mailing lists and appeal to the DPL / tech-ctte
/ a GR in case of stuckness", it is still a mechanism, at least for my
rhetorical purposes :-)
> Never having personally encountered a serious problem with an
> intransigent maintainer, I do not know much about it, but now you make
> me curious.
Sorry to have raised your expectations unwarrantedly.
--
Henning Makholm "Monarki, er ikke noget materielt ... Borger!"
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-08-26, 7:56 am |
| * W. Borgert:
> A fine way to do this, is by having a pkg- project at
> alioth.debian.org.
Please keep in mind that responsible maintainers do not depend on
unmaintained services such as alioth.debian.org. If you must use it,
make sure that you make periodic copies of archives stored on costa.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Raphael Hertzog 2005-08-26, 8:51 pm |
| Florian,
Le vendredi 26 août 2005 à 11:20 +0200, Florian Weimer a écrit :
> Please keep in mind that responsible maintainers do not depend on
> unmaintained services such as alioth.debian.org.
YOU MUST STOP YOUR ANTI-ALIOTH CAMPAIGN !
As an alioth admin, I feel attacked each time I read one of your mail
and it's getting incredingly annoying.
> If you must use it, make sure that you make periodic copies of
> archives stored on costa.
That's a reasonable advice in any case...
Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com
Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christian Perrier 2005-08-27, 2:51 am |
| Quoting Florian Weimer (fw@deneb.enyo.de):
> Please keep in mind that responsible maintainers do not depend on
> unmaintained services such as alioth.debian.org. If you must use it,
> make sure that you make periodic copies of archives stored on costa.
Well, I'm afraid that I'm not a responsible maintainer, then....:-)
So is the d-i team, the testing security team and so on.
Maybe alioth maintenance does not fit your own admin quality reference
system.
Then, I see a few solutions to this:
-contribute to alioth system administration
-make constructive suggestions (constructive suggestions are
argumented suggestions and sometimes accept that people do not agree
with what you suggest)
-do not use it
-build a concurrent collaborative development environment and convince
people that it's better than alioth
As far as I know, Alioth maintenance is handled by the relevant people
on their free time, as a volunteer work (just like all work we do in
this project). Thus they deserve some respect for the time they invest
in it. *Even* if you do not agree with their technical choices or
method of work.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-08-27, 7:56 am |
| * Christian Perrier:
> Well, I'm afraid that I'm not a responsible maintainer, then....:-)
But you do keep backups, I hope.
> Maybe alioth maintenance does not fit your own admin quality reference
> system.=20
I'm not the only one who is complaining.
> Then, I see a few solutions to this:
>
> -contribute to alioth system administration
This isn't possible, apparently, see Rapha=EBl's message
<1125049640.15162.45.camel@pianobar.home.ouaza.com> and its
follow-ups. Even DSA doesn't contribute to system maintenance.
> -make constructive suggestions (constructive suggestions are
> argumented suggestions and sometimes accept that people do not agree
> with what you suggest)
I made a suggestion which was trivial to implement and did fix a real
problem. Check the mail archives to see how long it took until it was
acted upon.
> As far as I know, Alioth maintenance is handled by the relevant
> people on their free time, as a volunteer work (just like all work
> we do in this project).
I've been privately told that an alioth admin demands hardware in
compensation for his Debian-related work, effectively blackmailing the
DPL. I don't know if this is true, I hope it's not.
| |
| Thijs Kinkhorst 2005-08-27, 7:56 am |
| On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote:
> I've been privately told that an alioth admin demands hardware in
> compensation for his Debian-related work, effectively blackmailing the
> DPL. I don't know if this is true, I hope it's not.
Making grave accusations based on rumours is very destructive behaviour.
Either you make claims you can back up with references, or you keep them
for yourself. This doesn't do any good for anyone.
Thanks
Thijs
| |
| Florian Weimer 2005-08-27, 7:56 am |
| * Thijs Kinkhorst:
> On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote:
>
> Making grave accusations based on rumours is very destructive behaviour.
> Either you make claims you can back up with references, or you keep them
> for yourself. This doesn't do any good for anyone.
I can't quote from private mail. I've checked the claim with someone
who knows the parties involved better than I, and he wasn't surprised
at all.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thijs Kinkhorst 2005-08-27, 7:56 am |
| On Sat, 2005-08-27 at 10:16 +0200, Florian Weimer wrote:
> * Thijs Kinkhorst:
>
>
> I can't quote from private mail. I've checked the claim with someone
> who knows the parties involved better than I, and he wasn't surprised
> at all.
Doesn't change my point: if you can't quote from that mail, don't make
unverifiable claims in a public forum. Either continue your quest in
private where you can back up your claim, or forget about it as long as
its not even remotely provable. Making unverifiable grave accusations in
public is never good, whatever the reasons that references are missing.
Thijs
| |
| Florian Weimer 2005-08-27, 7:56 am |
| * Thijs Kinkhorst:
> unverifiable grave accusations
It's not unverifiable (you can ask the DPL if you wish, or the admins
involved), and it's not a very grave accusation, either. See it as an
encouragement to make backups of your data on Debian's machines.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thijs Kinkhorst 2005-08-27, 7:56 am |
| On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote:
> * Thijs Kinkhorst:
>
>
> It's not unverifiable (you can ask the DPL if you wish, or the admins
> involved), and it's not a very grave accusation, either. See it as an
> encouragement to make backups of your data on Debian's machines.
"blackmailing the DPL" is not a grave accusation? You must be kidding.
If you really think this should be treated in public, find proof for it:
people who are willing to back up your claim in public, not just in
private mail. If you can't find anyone who wants this, bad luck, stop
it.
Thijs
| |
| Andreas Barth 2005-08-27, 7:56 am |
| Hi,
(that I answer to this mail is just pure Chance - it's meant at you
both, and I might have answered to another mail equally well
* Thijs Kinkhorst (kink@squirrelmail.org) [050827 10:46]:
> On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote:
[vbcol=seagreen]
> "blackmailing the DPL" is not a grave accusation? You must be kidding.
Please: remember that we all tend sometimes to say too harsh things in
mail (or rather, we forget that this is not some chit-chat, and
everything is printed and archived), and also that it's way too easy to
over-interpret someone else, as we just have the text, and not the
emotional suroundings (tone, face expressions, ...).
So, please let's keep the level down.
Cheers,
Andi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-27, 8:49 pm |
| On Sat, Aug 27, 2005 at 10:16:58AM +0200, Florian Weimer wrote:
> * Thijs Kinkhorst:
>
> I can't quote from private mail.
If you can't quote from private mail, then don't mention it. Please.
> I've checked the claim with someone who knows the parties involved
> better than I, and he wasn't surprised at all.
I've been privately told that you've been seen doing stuff with a duck.
I don't know if this is true, I hope it's not. I've checked the claim
with someone who knows you better than I do, and he wasn't surprised at
all.
(no, this isn't true. But I hope you get my point. Either back up your
accusations, or keep them for yourself.)
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-08-31, 6:01 pm |
| * Andreas Barth:
> Please: remember that we all tend sometimes to say too harsh things in
> mail (or rather, we forget that this is not some chit-chat, and
> everything is printed and archived), and also that it's way too easy to
> over-interpret someone else, as we just have the text, and not the
> emotional suroundings (tone, face expressions, ...).
And from time to time, I can really understand fellow developers who
resort to threats in a desperate attempt to move things forward. 8-(
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|