Thoughts on Debian quality, including automated testing

classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Joey Hess
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 than their little
> package feifdom. It might help overcome the sense that key people aren't
> communicating, as well as provide more easy avenues for NM's to get
> involved that don't simply involve packaging some crap little script from
> freshmeat.
>  - David Nusinow
>
> [0] A Debian Games team would be a perfect hypothetical example of this. So
>     is the Debian libruby extras team I helped create.
That's a terrific idea, and I think a games team is, besides being a
good eample, worth doing.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Felipe Sateler
In reply to this post by David Nusinow
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 sponsor for my package, I'd have the chance to talk
directly to a group related to my package, and (ideally) get a quicker
response.

--


 Felipe Sateler

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Lars Wirzenius
In reply to this post by Roger Leigh
ke, 2005-12-21 kello 14:19 +0000, 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 and older architectures, this is
> an advantage.

Right. I'll postpone adding support for this until later, then. For the
time being, I assume piuparts will mostly be run on relatively fast
machines. Once slow machines become more relevant for piuparts, I'll
return to this issue and will look at schroot in more detail. Thanks for
pointing it out, I didn't know about it before.

(Likewise, UML/Xen support will probably happen only later.)

--
Never underestimate the power of a small tactical Lisp interpreter.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Andrew Suffield
In reply to this post by Thomas Hood-3
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
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.

Debian is a great example of this problem in practice. Most of the
more significant teams show this problem to one degree or
another. Common places where it appears are ftp-master, debian-admin,
and scud. You get a lot of people able to meddle with something but
none of them responsible for actually seeing that it gets done - and
so some of it just doesn't get done.

The NEW queue used to get backed up all the time for exactly this
reason. The problem went away when one person became responsible for
processing it. Replacing teams with individuals usually works better,
where it's actually possible. When it isn't, you probably need to
break up the task more until it is.

We would all be much worse off with the abolition of individual
responsibility. If I were feeling in a conspiracy-theorist mood then
I'd suggest that those who are promoting team maintainance are trying
to gain power while evading responsibility. But frankly I think that's
giving them too much credit.

--
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Mark brown-22
In reply to this post by Thomas Hood-6
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.  

...

> You are saying that requiring people to find co-maintainers is
> "bureaucracy"?

It seems to me that if you're talking about a lip service approach like
the above being OK then the focus isn't really on solving the problem
any more, it's on having people jump through a given set of hoops.  This
doesn't really achieve the end result you're looking for.

>                 Someone I know well recently got co-maintainers for
> three of his packages by posting a single message to debian-devel.
> That's less of a burden than that imposed by many another Debian rule.

Conversely, the reason I ended up maintaining the NIS package is that
I'm the only person who stepped up and actually did anything when the
previous maintainer asked for help.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Thomas Hood-6
In reply to this post by Lars Wirzenius-2
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 legitimate objection.  I was assuming that the main reason for
undermaintenance is lack of time and reluctance to give up control,
rather than lack of motivation.  If the problem is lack of motivation,
and the chief motivator is a sense of responsibility, then you don't want
to diffuse that.

> We would all be much worse off with the abolition of individual
> responsibility.

The constitution already abolished it -- at least, if you interpret
article 2.1 the way some people have.

Maybe it would be useful to reinforce a sense of responsibility in Debian.

> If I were feeling in a conspiracy-theorist mood then
> I'd suggest that those who are promoting team maintainance are trying
> to gain power while evading responsibility.

Well, you do suggest it here.  And what you suggest makes no sense, so
let's not rule out the possibility that you are in fact paranoid.
--
Thomas Hood


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Steve Greenland
In reply to this post by Thomas Hood-6
On 21-Dec-05, 13:10 (CST), Thomas Hood <[hidden email]> 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.  Lone
> can carry on working as before and find a co-maintainer who won't get
> in his way.

Or, the Lone Ranger can say "screw this crap" and orphan all her
packages.

> In other words, this rule can have only positive effects.  :)

That doesn't sound too positive to me.

If you think it's acceptable, under the "must have a co-maintainer"
rule, to have a co-maintainer who doesn't actually do anything except
have their name in the control file, it's pretty clear that the rule is
pure bureaucracy.

Yes, there are some maintainers and/or some packages for which
co-maintenance is a good idea. Luckily, they seem to be figuring it out
on their own. If you have some particular packages in mind, go offer to
help.

Steve

--
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Kari Pahula-2
In reply to this post by Thomas Hood-3
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 think a more basic requirement here is to expect
maintainers to act responsibly.  Let them recognize the best ways to
maintain a package for themselves.  Telling them they must work in a certain
manner is disparaging.

If there are cases where team maintainership would clearly solve a problem
yet the maintainer will refuse to turn over the package to TM, then it is
valid to question whether that maintainer is acting responsibly.  But
otherwise, team maintainership is a solution looking for a problem.

I'm not against advocating for TM, but please do so in a case by case basis.

Other than that, enable, don't force.  If you think that TM is great try to
convince people, set an example and show people how it can be done but don't
set rules.  The goal of Debian remains to create a free operating system and
it doesn't matter how we get there.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Manoj Srivastava
In reply to this post by Thomas Hood-3
On Wed, 21 Dec 2005 12:23:32 +0100, Thomas Hood
<[hidden email]> 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 everyone likes to work in a
>> close team, either, and we shouldn't exclude them.

> I don't think that it is ridiculous to require that every package
> have a team behind it---i.e., at least two maintainers.


        While opinions are fine, I personally do not share yours in
 this regards.

> 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 person) is an asset to Debian.

        Hmm. The question is, can I find someone whose judgement I can
 trust, who has the time to spend on it, and who would not require me
 to change my methodology to the extent that would make managing my
 packages to burdensome for me.

        Well, so far, I have not gotten co-maintainers. I am not sure
 I am going to spend a whole lot of effort to garner any, anyway, since
 I am not yet convinced that diluting responsibility for my packages
 would be a net win for my users.

        And if you are saying that you consider me and my packages not
 to be an asset to Debian, than all I can respond with is amusement.


> Second, putting packages in the custody of a team makes it easy for
> a tired maintainer to relinquish control.

        When I get that tired, I'll follow the established mechanisms
 for relinquishing control. I do not need to carry bureaucratic
 baggage for years in order to facilitate letting go when I need to.  

> If the team works via an alioth project then there are many
> benefits. Code is kept under version control and thus backed up; the
> change history can be easily viewed by anyone; the mailing list
> becomes an easily browsed history of package development.  Team
> maintainership is working very well for some other distributions.

        None of this requires a team. (take a look at
 http://arch.debian.org/arch/private/srivasta  before you think of
 refuting this statement).

> 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.

        Silly requirements like this would just be crying to be
 flouted. I, for one, have absolutely no intention of  listening to
 such.

        Personally, a board is made of wood, and bureaucratic
 ossification and dilution of responsibility when  doing a task is
 someone elses responsibility don't always improve matters.

        manoj
--
Why use Windows, since there is a door? (By
[hidden email], Andre Fachat)
Manoj Srivastava   <[hidden email]>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Manoj Srivastava
In reply to this post by Steve Greenland
On Wed, 21 Dec 2005 17:52:21 -0600, Steve Greenland <[hidden email]> said:

> On 21-Dec-05, 13:10 (CST), Thomas Hood <[hidden email]> 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.
>> Lone can carry on working as before and find a co-maintainer who
>> won't get in his way.

> Or, the Lone Ranger can say "screw this crap" and orphan all her
> packages.

        Or, say screw this crap, and proceed to ignore the dictum.

        manoj
--
Love your enemies: they'll go crazy trying to figure out what you're
up to.
Manoj Srivastava   <[hidden email]>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Andrew Vaughan
In reply to this post by David Nusinow
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 better.
>
> I think a two-maintainer rule is a bit artificial and perhaps the wrong
> solution. Taking a cue from teams that work well in Debian (Gnome, d-i,
> etc) indicates that somewhat larger teams with a common goal and a fairly
> large set of packages under their umbrella will work in practice. This
> provides the opportunity for autonomy (someone can take ownership of a
> package within the team) but also a cohesiveness and a known set of
> people to turn to when you're in need.
>
> It's pretty simple to found such a team too. All it takes is some
> interested people and an alioth project.
>
>  - David Nusinow

I was about to suggest exactly that.  

Thanks David

Andrew


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by Russ Allbery-2
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.

Amen.

-- vbi

--
Wir Menschen lieben nicht, um zu hassen; aber wohl hassen wir, um zu
lieben.
                -- Jean Paul

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by Thomas Hood-6
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 Tonto won't be efficient, because he doesn't know more than Joe
Random Developer (remember, the reason why Lone picked him was that he
'doesn't get in the way', which will frequently mean that he'll not be
interested in the package anymore by the time his attention would be
needed.)

-- vbi

--
featured product: SpamAssassin - http://spamassassin.org

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Christian Perrier
In reply to this post by Thomas Hood-6

> > 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 to find co-maintainers is
> "bureaucracy"?  Someone I know well recently got co-maintainers for
> three of his packages by posting a single message to debian-devel.


I think that what Erinn wants to say is more that *forcing* (or
putting pressure on) maintainers to find co-maintainers would be
"bureaucracy".

I think that she will however agree that *encouraging* co-maintenance
for "key" or "important" packages (which is a very vague definition)
is one of the ways to go. But she will probably be able to say it by
herself: I'm just interpreting....

The word "bureaucracy" here has of course a negative meaning for
"constraints that are felt unneeded"....which I mostly agree with.
I sometimes defend the idea that bureaucracy may be needed but I'm not
sure it's needed here.




--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by David Nusinow
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 interested in team maintainership and communication with other
developers can and do form teams.  People not interested in team
maintainership currently most often don't.

In some cases (probably most), the latter are doing a fine job.  In some
cases they don't.  In some cases they use 'help' tags and RFAs, but
sometimes they won't admit it by asking for help - this last category is
the only one that is problematic and I think it's quite small.

Solution?  *IF* people are found who would take over these packages, ask for
change of maintainer.  If maintainer won't give up the badly-maintained
package?  Difficult.  Perhaps QA may want to voice an official verdict that
package X is in need of a new maint?  Perhaps the people interested in
maintaining will just hijack it?  In either cases, toe-stomping is going
on, and rude words or people leaving Debian is likely to follow - but I
don't believe there is an easy solution here, and I don't believe that
forcing team-maint on this class of maintainers will solve the situation.

-- vbi

--
The content of this message may or may not reflect the opinion of me, my
employer, my girlfriend, my cat or anybody else, regardless of the fact
whether such an employer, girlfriend, cat, or anybody else exists.  I
(or my employer, girlfriend, cat or whoever) disclaim any legal
obligations resulting from the above message.  You, as the reader of
this message, may or may not have the permission to redistribute this
message as a whole or in parts, verbatim or in modified form, or to
distribute any message at all.

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Frank Küster
In reply to this post by David Nusinow
David Nusinow <[hidden email]> wrote:

> On Wed, Dec 21, 2005 at 11:00:15AM -0500, Erinn Clark wrote:
>> * Thomas Hood <[hidden email]> [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 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 than their little
> package feifdom. It might help overcome the sense that key people aren't
> communicating, as well as provide more easy avenues for NM's to get
> involved that don't simply involve packaging some crap little script from
> freshmeat.

That sounds good, but there's a back side, too: If you maintain a couple
of packages in different fields, you'd be forced to be part of a couple
of these large-scale teams, and this could create a lot of unnecessary
work - and if it's just to learn which information to ignore.  For
example, I currently maintain two packages:

- teTeX, which is already team-maintained, but a large-scale team could
  be formed with the maintainers of all TeX-related packages (many of
  them maintained by people who are just users and mostly interested in
  different things)

- netenv, a network environment chooser for laptops - this would mean
  I'd be part of a "network stuff" team

If I find time, my next project within Debian would be to package
JabRef, a bibliography database that nicely works together with LaTeX,
but is written in Java and would mean for me to be part of the Java
team.

Being part of three large-scale teams would clearly be too much for me
(at least if I really want to be part, and not just receive mail which
is promptly sent to /dev/null), meaning I would have to give away one of
the packages.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Andrew Suffield
In reply to this post by Thomas Hood-6
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. People who maintain significant
packages tend to be busy. Their reason for doing one thing over
another will be primarily dependent on what they want to do, and what
they feel they *should* do.

> > We would all be much worse off with the abolition of individual
> > responsibility.
>
> The constitution already abolished it -- at least, if you interpret
> article 2.1 the way some people have.

I consider 'individual responsibility' to be a matter of personal
ethics, not enforced punishment. We do have a few morally bankrupt
maintainers (or, non-maintainers). I think the majority of developers
have some sense of responsibility, though. This belief is primarily
founded on the fact that I don't think Debian could have survived this
long at this size without it.

> Maybe it would be useful to reinforce a sense of responsibility in Debian.

You can't reinforce or enforce ethics - attempting to do so merely
gives you obedience, or a herd mentality. And I don't think that a
blame culture will accomplish anything.

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 the tools have now advanced to the point where this
is a practical option.

In general you're always far better off forcing every *change* to a
given component to go through a single individual. Large projects need
a pumpking, because dogpiling creates lousy software. For Debian this
would be cumbersome and unwieldy as a rule, but some high-importance
tasks could benefit from it.

--
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Thomas Hood-6
In reply to this post by Lars Wirzenius-2
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 to improve it?

Lars's headings were:

    A) Prevent bugs from happening in the first place
    B) Find and report bugs
    C) Fix bugs that have been reported
    D) Prevent bugs from entering the archive
    Automated testing of program functionality
    Let's take quality assurance seriously

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?

For C, Lars discussed different degrees of shift from solitary toward
collective maintainership.  In the sequel opinions were emphatically
expressed that such a shift is not necessarily a good thing.  The
question remains whether better quality can be realized by changing
the organization in some way.  Perhaps not.  Then what other things
can be done to help individual maintainers fix more bugs and fix them
better?
--
Thomas Hood


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Raphael Hertzog-3
In reply to this post by Thomas Hood-6
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 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.  

Unfortunately, this is simply not true for many small packages. None of my
packages are maintained in a team. I tried several times to get help for
libdbd-pg-perl and libdbd-mysql-perl but I never got any (except once).
(Now, I should probably move them to pkg-perl on alioth but I haven't
took the time to do that yet)

That is to say: you can't require the actual maintainer to find
co-maintainer by himself.

I do agree that maintaining more packages in team is a good idea but you
can't decide that it's the rule and be done. What you can do however, is
to work in that direction (like I do).

For example, you could have participated in the thread in debian-qa that I
recently started about "Collaborative maintenance", and put your brightest
ideas in the wiki :
http://wiki.debian.org/CollaborativeMaintenance
http://lists.debian.org/debian-qa/2005/12/msg00026.html

Or more concretely, you can help the maintainers find people to help. I'm
convinced that most maintainers of packages of priority standard or higher
have absolutely nothing against team maintenance but they simply didn't
took the time to organize this. So help them organize the transition !
Find co-maintainers, request an alioth project (or join an already
existing team) and get done with it. Start again with another package...

> In other words, this rule can have only positive effects.  :)

The Debian world has no "police" to force the application of any rule.
Governing the Debian world requires common sense, communication skills
and much time !

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Raphael Hertzog-3
In reply to this post by Daniel Ruoso
On Wed, 21 Dec 2005, Daniel Ruoso wrote:
> Em Qua, 2005-12-21 às 14:34 +0000, 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 happy if the uploader knows how I
> maintain the packages (I mean, using CVS, SVN or such) and cooperate
> using such tools.

This is legitimate.

> 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 self-include in the
> Uploaders field, to acquire responsability also)...

This is definitely required. If I had time, I would have drafted such a
proposal for the Debian policy.

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.

Example:
VCS-Maint-Repository: svn://svn.debian.org/svn/pkg-gnome/packages/unstable/gksu
VCS-Maint-Repository: cvs://cvs.debian.org/debian-boot/debian-cd
VCS-Maint-Repository: none

We may also need to be able to specify multiple repositories: for example,
if several branches are maintained in parallel (unstable/experimental), or
maybe for derived distributions like Ubuntu which may want to list there,
the URL of the "branch" that they're maintaining on top of the original
Debian package.

BTW, at the same time, it would be good to add more similar meta-data like
"VCS-Upstream-Repository" or "Upstream-Website" which are definitely
needed to make the PTS effective for QA workers which need to find out the
upstream website/community to seek help, to check for potential patches, etc.

Be my guest, and formalize such a proposal for debian-policy. :-)

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12345