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 t
[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.
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 an
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 "D
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 se
-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
> "
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 consen
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 whatsoeve
Emanuele Rocca <[EMAIL PROTECTED]> wrote:
> Hello,
>
> * Frank Küster <[EMAIL PROTECTED]>, [2005-12-27 10:12 +0100]:
>> Anthony Towns 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)
>>
>> Wit
Hello,
* Frank Küster <[EMAIL PROTECTED]>, [2005-12-27 10:12 +0100]:
> Anthony Towns 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 non-DD team membe
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 solution in the
>> team.
>
> It's nice
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 *i
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 s
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
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 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
> >
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
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..
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
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 "bu
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 infrastructure
[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 g
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 oth
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 poi
* 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 th
> 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
o
* 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
>
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 ma
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/
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 ha
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
[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
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.
Hm
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 seque
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 l
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'
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 li
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 recipro
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
done
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 hu
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.
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
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 int
> > 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 requi
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 tha
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 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
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 poss
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 waste
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
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 a
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 l
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.
...
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
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 machin
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 s
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 rat
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
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 ha
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 wi
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
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 ar
* 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.
>
>
> 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]
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
> th
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 agr
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
Descriptio
[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
* 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 the
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
-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
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
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
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
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 qu
-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 befo
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 wa
78 matches
Mail list logo
