* 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
Quoting Florian Weimer ([EMAIL PROTECTED]):
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
* 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.
I'm not the only one who is complaining.
Then, I see a few solutions to this:
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
* Thijs Kinkhorst:
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
On Sat, 2005-08-27 at 10:16 +0200, Florian Weimer wrote:
* Thijs Kinkhorst:
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
* 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 [EMAIL
On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote:
* 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
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 ([EMAIL PROTECTED]) [050827 10:46]:
On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote:
* Thijs Kinkhorst:
unverifiable grave
On Sat, Aug 27, 2005 at 10:16:58AM +0200, Florian Weimer wrote:
* Thijs Kinkhorst:
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
* 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.
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
Scripsit Thaddeus H. Black [EMAIL PROTECTED]
Henning Makholm wrote:
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
On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst
[EMAIL PROTECTED] 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
On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst
[EMAIL PROTECTED] wrote:
On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst 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
Scripsit Marc Haber [EMAIL PROTECTED]
On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst
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
On Thu, Aug 18, 2005 at 10:33:53AM +0200, Marc Haber wrote:
On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst
[EMAIL PROTECTED] 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
Henning Makholm wrote:
Scripsit Marc Haber [EMAIL PROTECTED]
On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst
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
Dear Wolfang,
* W. Borgert [EMAIL PROTECTED] [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
[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
On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote:
[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
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
On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote:
[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
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.
/*
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:
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
On Tue, August 16, 2005 15:46, Wouter Verhelst wrote:
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
Le Mardi 16 Août 2005 16:09, Steinar H. Gunderson a écrit :
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
[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
On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst wrote:
On Tue, August 16, 2005 15:46, Wouter Verhelst wrote:
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
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
Hi!
* Florent Bayle [EMAIL PROTECTED] [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
Scripsit Wouter Verhelst [EMAIL PROTECTED]
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
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
On Tue, Aug 16, 2005 at 09:15:11PM +, W. Borgert wrote:
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
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
W. Borgert [EMAIL PROTECTED] 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.
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
On Sun, Aug 14, 2005 at 02:15:43PM +, 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
On Mon, 2005-08-15 at 06:14 +, 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.
On Mon, 15 Aug 2005, Paul TBBle Hampson wrote:
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
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.
also sprach W. Borgert [EMAIL PROTECTED] [2005.08.14.1615 +0200]:
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.
[...]
VIII. Packages not maintained by teams are not to
On 10381 March 1977, W. Borgert wrote:
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams.
No, thanks.
VI. The advantages of team maintenance outweigh the problem of
team maintenance overhead.
Not everywhere, no.
VII. Team maintainence helps
[W. Borgert]
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams.
I agree that it is good to maintain packages in teams, to make sure
the project is less vulnerable to single maintainers going on
vacation, becoming sick, being run over by a bus or other
W. Borgert wrote:
VIII. Packages not maintained by teams are not to go into
unstable/testing/stable.
Does this mean you are volunteering as a team member for all packages
that currently have only one maintainer?
--
Antti-Juhani
signature.asc
Description: OpenPGP digital signature
On Aug 14, W. Borgert [EMAIL PROTECTED] wrote:
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams. A fine way to do this, is by
One size fits all methods are a bad idea. Different packages and
different maintainers have different requirements.
--
On Sun, Aug 14, 2005 at 08:45:43PM +0200, Marco d'Itri wrote:
On Aug 14, W. Borgert [EMAIL PROTECTED] wrote:
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams. A fine way to do this, is by
One size fits all methods are a bad idea. Different
On Sun, 14 Aug 2005, W. Borgert wrote:
[snip]
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.]
W. Borgert writes:
as a conclusion of many discussions at DebConf5, I propose to maintain
all packages by teams.
You would have a team maintain 'units'? That's silly.
--
John Hasler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Sun, Aug 14, 2005 at 03:52:55PM -0500, Adam Heath wrote:
Haha, this gave me a good laugh for an email. Altho, as far as jokes go, this
was rather poorly delivered.
If I would make my living as an entertainer or comedian, I would
have to live on social security or be hungry :-( Sorry.
On Sun, Aug 14, 2005 at 03:42:23PM -0500, John Hasler wrote:
You would have a team maintain 'units'? That's silly.
If the team maintains only the package 'units', yes. If the
same team maintains multiple relating packages, it's different.
E.g. the Debian XML/SGML group maintains 22 packages.
[John Hasler]
You would have a team maintain 'units'? That's silly.
I guess it is equally silly as it is to maintain prebaseconfig in a
team. The prebaseconfig package is very simple, and maintained by a
team together with a lot of other very simple packages. It works
quite well to maintain
I wrote:
You would have a team maintain 'units'? That's silly.
W. Borgert writes:
If the team maintains only the package 'units', yes. If the
same team maintains multiple relating packages, it's different.
There are no packages related to units.
--
John Hasler
--
To UNSUBSCRIBE, email
On Sun, Aug 14, 2005 at 11:28:41PM +0200, Petter Reinholdtsen wrote:
I guess it is equally silly as it is to maintain prebaseconfig in a
team. The prebaseconfig package is very simple, and maintained by a
team together with a lot of other very simple packages. It works
quite well to maintain
On Sun, 2005-08-14 at 14:15 +, 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.
On Sun, Aug 14, 2005 at 02:15:43PM +, 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
On Aug 15, John Goerzen [EMAIL PROTECTED] 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
On Mon, Aug 15, 2005 at 05:08:00AM +0200, Marco d'Itri wrote:
On Aug 15, John Goerzen [EMAIL PROTECTED] 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
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
59 matches
Mail list logo
