Hi,
Sorry for the late response, but I was on VAC for a while and my
backlog is always long:
* Let's modify pbuilder to run test-build tests and (if
possible) also the generic tool and test-install tests.
These belong, I think, better into pbuilder then piuparts,
Hello
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
First, thanks to Lars for drawing our attention to an important topic
and for taking an initiative that is long overdue.
Lars, I agree fully with what you say. When it comes to team
maintenance I would go even further than
[Frank Küster]
You are right - I was under the impression that this means people
who will do maintainer uploads of this package, but in fact it just
says maintainers in the Policy.
Right, the field is misnamed, it should be Maintainers: but that
might be slightly confusing, visually.
ke, 2005-12-28 kello 02:00 +0100, Moritz Muehlenhoff kirjoitti:
Why don't we add a status field into the PTS, where a maintainer
can denote her NMU policy for a given source package? E.g.
a selection box, ranging from Don't dare to touch this, I bite
to Feel free to 0d-NMU for every severity
On Thu, Dec 29, 2005 at 03:46:08PM +0200, Lars Wirzenius wrote:
ke, 2005-12-28 kello 02:00 +0100, Moritz Muehlenhoff kirjoitti:
Why don't we add a status field into the PTS, where a maintainer
can denote her NMU policy for a given source package? E.g. a
selection box, ranging from Don't dare
On Thu, Dec 29, 2005 at 04:31:22PM +0100, Lionel Elie Mamane wrote:
http://wiki.debian.org/LowThresholdNmu
Thanks, but I can't find the edit link or button. Is it well hidden
or am I going blind?
wiki.debian.org uses MoinMoin, which is this odd sort of psuedo-wiki; you
have to register and log
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moritz Muehlenhoff [EMAIL PROTECTED] writes:
Why don't we add a status field into the PTS, where a maintainer can
denote her NMU policy for a given source package? E.g. a
selection box, ranging from Don't dare to touch this, I bite to
Feel free
Anthony Towns aj@azure.humbug.org.au wrote:
On Sat, Dec 24, 2005 at 10:11:57AM +0100, Frank Küster wrote:
The difference is who does the work.
I a well-team-maintained package, the work is actually done by the
team, and decisions are made after finding a consensus solution in the
team.
Hello,
* Frank Küster [EMAIL PROTECTED], [2005-12-27 10:12 +0100]:
Anthony Towns aj@azure.humbug.org.au wrote:
(There's plenty of ways to make that not a problem, such as using the
Uploaders: field; but the above might be a useful datapoint)
With the Uploaders field, you miss all
Emanuele Rocca [EMAIL PROTECTED] wrote:
Hello,
* Frank Küster [EMAIL PROTECTED], [2005-12-27 10:12 +0100]:
Anthony Towns aj@azure.humbug.org.au wrote:
(There's plenty of ways to make that not a problem, such as using the
Uploaders: field; but the above might be a useful datapoint)
Lars Wirzenius wrote:
[Less strong ownership of packages.
This idea hasn't been tested. It could be tested if
some group of maintainers declared that some or all
of their packages were part of the experiment, that
anyone could NMU them for any reason whatsoever, as
On Mon, Dec 26, 2005 at 01:03:21AM +1000, Anthony Towns wrote:
On Sat, Dec 24, 2005 at 10:11:57AM +0100, Frank Küster wrote:
The difference is who does the work.
I a well-team-maintained package, the work is actually done by the
team, and decisions are made after finding a consensus
On Sat, Dec 24, 2005 at 10:11:57AM +0100, Frank Küster wrote:
The difference is who does the work.
I a well-team-maintained package, the work is actually done by the
team, and decisions are made after finding a consensus solution in the
team.
It's nice to know who the team actually *is*
Benjamin Seidenberg [EMAIL PROTECTED] wrote:
Andrew Suffield wrote:
On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
Instead, why not propose a Responsible-For: header for control that
lists a person inside the project who the buck stops with in the
case of an applicant
Frank Küster wrote:
Benjamin Seidenberg [EMAIL PROTECTED] wrote:
Andrew Suffield wrote:
On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
Instead, why not propose a Responsible-For: header for control that
lists a person inside the project who the buck
I fully support your campaign Lars. I've ever been willing to write
automatic tests for a lot of packages of mine. And even a large subset
of them (all OCaml related ones for example) can benefit of the very
same test applied to them. I never added the test simply because there
is no
On Thu, Dec 22, 2005 at 10:43:34AM +0100, Thijs Kinkhorst wrote:
On Thu, 2005-12-22 at 08:38 +, Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck
On Fri, Dec 23, 2005 at 08:40:22AM +0100, Adrian von Bidder wrote:
The other side, and we've seen some people say this in this thread already,
is that even if a maintainer asks for help, he may not get any - IIRC nis
was one such package, and I claim that its still used by quite a few, so in
Em Sex, 2005-12-23 às 00:46 +0100, Raphael Hertzog escreveu:
On Thu, 22 Dec 2005, Daniel Ruoso wrote:
So, the nicest way is to create yet another subsystem that would manage
this type of information, and once many people starts putting
information there, the PTS will include it also...
Why
Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck stops here guy for that
package. Not an applicant, not a mailing list, and not a group of
people. I believe
On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck stops here guy for that
package.
Andrew Suffield wrote:
On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck stops
On Wed, Dec 21, 2005 at 11:17:43PM +0100, Thomas Hood wrote:
If the problem is lack of motivation,
and the chief motivator is a sense of responsibility, then you don't want
to diffuse that.
Specifically motivation to do *this* task, rather than any of the
others in the pile that need doing.
For the record, I have been favorable to team maintenance for years.
That's why the PTS begs for co-maintainers on packages of priority
standard or higher. That's why I pushed to setup alioth.debian.org.
On Wed, 21 Dec 2005, Thomas Hood wrote:
It turns out that there is no need for them to be
Since I contributed to taking the thread off on a particular tangent
I feel I should try to bring it back to its original topic, which
is an important one.
I would like to hear some discussion about whether or not the quality
of Debian is high enough; and if it is not high enough, what can be
On Wed, 21 Dec 2005, Daniel Ruoso wrote:
Em Qua, 2005-12-21 às 14:34 +, Matthew Garrett escreveu:
I think I've said this before, but I have no objections to anyone
uploading any of my packages. I'd be even happier if anyone who did so
was willing to enter into some sort of reciprocal
On Thu, 2005-12-22 at 08:38 +, Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck stops here guy for that
package. Not an applicant, not a mailing list,
Thomas Hood [EMAIL PROTECTED] wrote:
Under most of these topics Lars discussed automated testing. Are
there objections to Lars's concrete proposals (e.g., standardization
on a way to invoke package specific tests)? Are there other ideas?
Should Debian do more auditing, for example?
I'm all
On Thursday 22 December 2005 09.38, Andrew Suffield wrote:
On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the buck stops here guy for that
package. Not an applicant, not a mailing list,
Thomas, sorry for continuing the debate still on this single aspect of Lars'
mail :-)
On Thursday 22 December 2005 10.02, Thomas Hood wrote:
C) Fix bugs that have been reported
For C, Lars discussed different degrees of shift from solitary toward
collective maintainership. In the sequel
On Thursday 22 December 2005 10.55, Frank Küster wrote:
- how many bugs does a package have
- how many have not been dealt with for n months (or days/weeks for RC
bugs)
Changing the default ordering on the bts web pages from bug age to 'last
action age' might already show some effect.
[Russ Allbery]
Also, I think this is a little silly for small packages. My
experience with this sort of volunteer work in other areas is that
if one person does nearly all the work on a regular basis, you're
not gaining that much by having a backup. The person who is
theoretically the
Em Qui, 2005-12-22 às 10:22 +0100, Raphael Hertzog escreveu:
On Wed, 21 Dec 2005, Daniel Ruoso wrote:
Maybe it would be interesting to have some information in the package
saying how the package is managed and the preferrable way of doing an
NMU (I actually, think that it's desirable to
Petter Reinholdtsen [EMAIL PROTECTED] writes:
[Russ Allbery]
Also, I think this is a little silly for small packages. My experience
with this sort of volunteer work in other areas is that if one person
does nearly all the work on a regular basis, you're not gaining that
much by having a
Frank Küster [EMAIL PROTECTED] writes:
It would be good if there was a way to find out problematic packages,
by extracting information about
- how many bugs does a package have
- how many of them don't have a single response
- how many have not been dealt with for n months (or days/weeks
Russ Allbery [EMAIL PROTECTED] wrote:
Frank Küster [EMAIL PROTECTED] writes:
It would be good if there was a way to find out problematic packages,
by extracting information about
- how many bugs does a package have
- how many of them don't have a single response
- how many have not been
* Christian Perrier [EMAIL PROTECTED] [2005:12:22 08:10 +0100]:
Bureaucracy is often designed to do lots of things better and it often
doesn't achieve them. It creates needless hassle, more 'paperwork', and
has very few benefits besides making people feel like they've done
something
The fact that a package is important (note: not referring to Priority
here) is not indicative of the amount of work necessary, nor is it
indicative of the amount of time and expertise a given maintainer has
for it.
Sure. However, an important package will more badly suffer from lack
of
* Russ Allbery [EMAIL PROTECTED] [2005:12:22 09:14 -0800]:
(debbugs's strong point is handling a small
number of bugs on *lots* of different packages; I find it somewhat
difficult to follow when dealing with a *lot* of bugs on a single
package.)
OT for this thread, but: do you notice this
On Thu, 22 Dec 2005, Daniel Ruoso wrote:
In the PTS, I'd like to be able to point people to the CVS/SVN/arch
repository used by the maintainers, however I can't because the
information is not stored, or is stored in a non-formal manner in
README.Debian.
Hmmm... You probably pointed out
On Wed, Dec 21, 2005 at 03:07:10PM +0100, Adrian von Bidder wrote:
On Wednesday 21 December 2005 12.23, Thomas Hood wrote:
I don't think that it is ridiculous to require that every package have a
team behind it---i.e., at least two maintainers. First, if someone can't
find ONE other
[lots of snippage]
I fear I don't see your point - and I feel you don't see mine.
Here's why I feel *forced* comaintainership is not a solution:
Maintainers divide in
(i) those who already work in teams on their packages
(ii) those who don't.
Ignore (i).
(ii) divides in
(a) those who do a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Wirzenius [EMAIL PROTECTED] writes:
Automated testing of program functionality
==
Automatic testing needs to happen in various contexts:
* When the package has been built, but before it
ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti:
For this task, you might find schroot(1) useful. It's a means of
accessing chroot environments, but it supports LVM snapshots as one
method.
Does this require the user to set up LVM somehow before using schroot?
This is a very quick
First, thanks to Lars for drawing our attention to an important topic
and for taking an initiative that is long overdue.
Lars, I agree fully with what you say. When it comes to team
maintenance I would go even further than you do. You say:
Mandatory teams for packages seems ridiculous to
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote:
Sloppiness tends to result in real problems sooner or later.
possible slogan for volatile-sloppy ? :)
Several ideas have been floating around for years on how to improve
this situation, of which I'd like to mention three. While
On Wednesday 21 December 2005 12.23, Thomas Hood wrote:
I don't think that it is ridiculous to require that every package have a
team behind it---i.e., at least two maintainers. First, if someone can't
find ONE other person willing to be named as a co-maintainer of a given
package then I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Wirzenius [EMAIL PROTECTED] writes:
ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti:
For this task, you might find schroot(1) useful. It's a means of
accessing chroot environments, but it supports LVM snapshots as one
method.
Does
Lars Wirzenius [EMAIL PROTECTED] wrote:
* Less strong ownership of packages.
(snip)
This idea hasn't been tested. It could be tested if
some group of maintainers declared that some or all
of their packages were part of the experiment, that
anyone could NMU
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 12:23 +0100]:
I don't think that it is ridiculous to require that every package have a
team behind it---i.e., at least two maintainers. First, if someone can't
find ONE other person willing to be named as a co-maintainer of a given
package then I
[Thomas Hood]
I don't think that it is ridiculous to require that every package
have a team behind it---i.e., at least two maintainers. First, if
someone can't find ONE other person willing to be named as a
co-maintainer of a given package then I would seriously doubt that
that package (or
On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote:
At the very minimum, I believe all base packages (those installed by
debootstrap by default) should have co-maintainers.
This sounds like a good compromise between the two sides of this
discussion.
Thijs
signature.asc
On Wed, Dec 21, 2005 at 11:00:15AM -0500, Erinn Clark wrote:
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 12:23 +0100]:
Team maintainership is working very well for some other distributions.
That may be true, but it's not a good argument for forcing such a
situation in Debian.
I agree that
I wrote:
I don't think that it is ridiculous to require that every package have
a team behind it---i.e., at least two maintainers. First, if someone
can't find ONE other person willing to be named as a co-maintainer of
a given package then I would seriously doubt that that package (or
that
True. However, the issue in question is whether or not it would be
better if they maintained in teams.
I imagine that it would not be better.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 17:32 +0100]:
Erinn Clark wrote:
There are plenty of people who are maintaining packages alone
that are doing an excellent job
True. However, the issue in question is whether or not it would be
better if they maintained in teams.
Forcing
On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote:
This is not a fair characterization of what the introduction of
a two-maintainer rule would be doing. No one should be insulted
by general rule changes designed to make Debian work better.
I think a two-maintainer rule is a bit
Thijs Kinkhorst [EMAIL PROTECTED] writes:
On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote:
At the very minimum, I believe all base packages (those installed by
debootstrap by default) should have co-maintainers.
This sounds like a good compromise between the two sides of this
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote:
Several ideas have been floating around for years on how to improve
this situation, of which I'd like to mention three. While I've here
used the number of bugs as the measure of a package's quality,
the same ideas might help with
Em Qua, 2005-12-21 às 14:34 +, Matthew Garrett escreveu:
I think I've said this before, but I have no objections to anyone
uploading any of my packages. I'd be even happier if anyone who did so
was willing to enter into some sort of reciprocal agreement.
So do I, but I would be really
Erinn Clark wrote:
For maintainers who are doing a lot of good work, there's simply not
enough to justify more people. Once there's already a certain level of
efficiency, adding another person is not going to increase it, and will
likely decrease it. I can't see the point of enforcing this as
David Nusinow wrote:
I agree that we shouldn't force teams on anyone, but I'd like to see more
large-scale teams encompassing loosely connected smaller packages[0]. If,
for no other reason, than for developers to claim ownership of (and by
extension responsibility for) the whole project rather
On Wednesday 21 December 2005 13:33, David Nusinow wrote:
I agree that we shouldn't force teams on anyone, but I'd like to see more
large-scale teams encompassing loosely connected smaller packages
This will also bring the side effect of making it easier for non-DDs: Now
instead of finding a
ke, 2005-12-21 kello 14:19 +, Roger Leigh kirjoitti:
The difference for a minimal chroot is not too great. The main
advantage of schroot LVM snapshotting is that the time is constant
irrespective of the size of the LV (it's copy-on-write), whereas for
tar it is linear. For slow machines
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
I would support requiring team maintainership because TM will be
beneficial in almost all cases and making it a requirement it cuts off a
lot of useless discussion.
Cute theory, gaping hole. Making a group of people responsible for
On Wed, Dec 21, 2005 at 08:10:03PM +0100, Thomas Hood wrote:
It turns out that there is no need for them to be hurt at all. Lone
can carry on working as before and find a co-maintainer who won't get
in his way. But when Lone falls off his horse he'll be glad that Tonto
is nearby.
...
Andrew Suffield wrote:
Cute theory, gaping hole. Making a group of people responsible for
something, rather than a single person, means that they can all spend
all their time passing the buck and hoping that one of the others
takes care of it, with the result that nobody does.
This is a
On 21-Dec-05, 13:10 (CST), Thomas Hood [EMAIL PROTECTED] wrote:
How much would this rule hurt those lone ranger maintainers you are
talking about, the ones who package everything perfectly and cannot
possibly do any better?
It turns out that there is no need for them to be hurt at all.
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
I don't think that it is ridiculous to require that every package have a
team behind it---i.e., at least two maintainers. First, if someone can't
Sorry, but I'm having an issue with the word require here. Call me
idealistic, but I
On Wed, 21 Dec 2005 12:23:32 +0100, Thomas Hood
[EMAIL PROTECTED] said:
Mandatory teams for packages seems ridiculous to me.
Lots of packages are so small that having to arrange a team for
them, even if it is only the effort to set up and subscribe to a
team mailing list, is wasteful. Not
On Wed, 21 Dec 2005 17:52:21 -0600, Steve Greenland [EMAIL PROTECTED] said:
On 21-Dec-05, 13:10 (CST), Thomas Hood [EMAIL PROTECTED] wrote:
How much would this rule hurt those lone ranger maintainers you
are talking about, the ones who package everything perfectly and
cannot possibly do any
On Thu, 22 Dec 2005 04:32, David Nusinow wrote:
On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote:
This is not a fair characterization of what the introduction of
a two-maintainer rule would be doing. No one should be insulted
by general rule changes designed to make Debian work
On Wednesday 21 December 2005 19.24, Russ Allbery wrote:
[mandatory comaintainers]
I think that the energy used to define these sorts of procedures is
probably better used finding a package with a large bug count and
volunteering to work with the maintainer to try to get the bug count
down.
On Wednesday 21 December 2005 20.10, Thomas Hood wrote:
It turns out that there is no need for them to be hurt at all. Lone
can carry on working as before and find a co-maintainer who won't get
in his way. But when Lone falls off his horse he'll be glad that Tonto
is nearby.
Except that
Bureaucracy is often designed to do lots of things better and it often
doesn't achieve them. It creates needless hassle, more 'paperwork', and
has very few benefits besides making people feel like they've done
something useful when they haven't.
You are saying that requiring people
On Wednesday 21 December 2005 18.32, David Nusinow wrote:
[teams like gnome, kde, d-i, kernel, ...]
It's pretty simple to found such a team too. All it takes is some
interested people and an alioth project.
And here you say the most important thing: it takes *interested* people.
People
David Nusinow [EMAIL PROTECTED] wrote:
On Wed, Dec 21, 2005 at 11:00:15AM -0500, Erinn Clark wrote:
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 12:23 +0100]:
Team maintainership is working very well for some other distributions.
That may be true, but it's not a good argument for forcing
Subject: Thoughts on Debian quality, including automated testing
[ I'm subscribed to -devel, no Cc required. I apologize for the
length, but it's only a bit over 3000 words. I hope the
section titles help, if you want to skip parts. ]
For some time now I have been thinking about ways to make
78 matches
Mail list logo
