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: {SPAM} Re: Thoughts on Debian quality, including automated testing

Daniel Ruoso
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 should I create yet another unofficial thing while we already have
> proper infrastructure in place to distribute meta-data about our packages ?

To test if it's a good idea...

daniel


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

Benjamin Seidenberg
In reply to this post by Andrew Suffield
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 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.
>
I think you have something here, but I think allowing an
applicant/mailing list in maintainer should be ok.
In the case of an applicant, if they're doine the work, they both
deserve the credit and should be the one to get all the messages that
the various debian infrastructures sends out (Archive scripts, BTS,
point of contact for security, etc). The latter also holds for mailing
lists.

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 or team maintained package?

Benjamin

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

Re: Thoughts on Debian quality, including automated testing

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

> I think you have something here, but I think allowing an
> applicant/mailing list in maintainer should be ok.
> In the case of an applicant, if they're doine the work, they

> both
> deserve the credit

I don't think we should be using the control file for this
purpose. Particularly since it does not and never has included a list
of the people who do most of the work on a given package. Consider
samba - the 'maintainer' hasn't been heard from in ages, and nowhere
in the control file are all the relevant people listed.

The obvious place for this information would be the changelog - this
is the current convention (again, see samba).

> and should be the one to get all the messages that
> the various debian infrastructures sends out (Archive scripts, BTS,
> point of contact for security, etc).

I *think* that the relevant infrastructure tools have now all been
fixed so that you don't have to use the Maintainer field to accomplish
this.

> 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 or team maintained package?

Because I don't see how it would be semantically different to the
Maintainer field. The distinction between them is not apparent (what
is Maintainer supposed to mean under this scheme?). And adding new
fields is more work, so you don't do it without a good reason.

--
  .''`.  ** 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

Benjamin Seidenberg
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 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.
>>>
>>>      
>>>
>
>  
>
>>I think you have something here, but I think allowing an
>>applicant/mailing list in maintainer should be ok.
>>In the case of an applicant, if they're doine the work, they
>>    
>>
>
>  
>
>>both
>>deserve the credit
>>    
>>
>
>I don't think we should be using the control file for this
>purpose. Particularly since it does not and never has included a list
>of the people who do most of the work on a given package. Consider
>samba - the 'maintainer' hasn't been heard from in ages, and nowhere
>in the control file are all the relevant people listed.
>
>The obvious place for this information would be the changelog - this
>is the current convention (again, see samba).
>  
>
Fair enough. The reason I think of maintainer as this is that it's the
most often seen item associating the package with a person. Example
being apt-cache show, the front-ends, the bts, etc.

>  
>
>>and should be the one to get all the messages that
>>the various debian infrastructures sends out (Archive scripts, BTS,
>>point of contact for security, etc).
>>    
>>
>
>I *think* that the relevant infrastructure tools have now all been
>fixed so that you don't have to use the Maintainer field to accomplish
>this.
>
>  
>
>>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 or team maintained package?
>>    
>>
>
>Because I don't see how it would be semantically different to the
>Maintainer field. The distinction between them is not apparent (what
>is Maintainer supposed to mean under this scheme?). And adding new
>fields is more work, so you don't do it without a good reason.
>
>  
>
The difference is who does the work. The Responsible field would be the
one to talk to if the package does something bad from the project's
perspective such as a deliberate security issue or it not being up to
snuff. They would also be the one to talk to if the maintainer or team
doesn't respond to other complaints. The maintainer would be the one
that users look to on a daily basis - manages bugs, does most of the
work, etc.

Basically, the Responsible field would be what you suggested - a Debian
Developer in good standing who offers accountability for the project.
The Maintainer would be the person or team doing the work, possibly a
mailing list or someone who is not a DD. The key is that the
Responsible-Person field would add accountability.

Benjamin


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

Re: Thoughts on Debian quality, including automated testing

Frank Küster
Benjamin Seidenberg <[hidden email]> 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 or team maintained package?
>>>
>>
>>Because I don't see how it would be semantically different to the
>>Maintainer field. The distinction between them is not apparent (what
>>is Maintainer supposed to mean under this scheme?). And adding new
>>fields is more work, so you don't do it without a good reason.
>>
>>
> 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.

> The Responsible field would be
> the one to talk to if the package does something bad from the
> project's perspective such as a deliberate security issue or it not
> being up to snuff.

I don't see why you wouldn't want to talk to the list in this case.  We
don't need someone to put the blame on (we don't have and don't want any
"punishment"), rather we need someone to make the necessary changes, be
it in the package or in the minds of the people who maintain the package.

> They would also be the one to talk to if the
> maintainer or team doesn't respond to other complaints. The maintainer
> would be the one that users look to on a daily basis - manages bugs,
> does most of the work, etc.

I really can't see the difference, neither in a team-maintained package
nor with an applicant.  In the latter case, of course the sponsor is
responsible; but even then there's not much point in talking to the
sponsor if the applicant can just search a new one.

If a package is badly maintained and you get no response, the usual
procedure is to start with NMUs and proceed with orphaning the package
(or taking over); where's the difference here between a non-responsive
single maintainer and a non-responsive team?

And in case of complaints about a package, how should someone be able to
make good decisions if he does *not* receive the messages about it on a
daily basis, but instead has to dig through them afterwards?  Well,
there might be rare cases where this is the only way to get an outside
view of some quarrel, but we already have the TC for this.

> Basically, the Responsible field would be what you suggested - a
> Debian Developer in good standing who offers accountability for the
> project.

Ah, so we're going to have two classes of DDs:  The ones with "good
standing", and the others who are not allowed to be in the Responsible
field?

> The Maintainer would be the person or team doing the work,
> possibly a mailing list or someone who is not a DD. The key is that
> the Responsible-Person field would add accountability.

Accountability?  That only makes sense if there are consequences in case
that person  does bad work.  Either a "criminal action", or some sort of
private punishment like having to pay money.  All this does not exist in
Debian, and IMO it doesn't make sense to introduce them.

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

Benjamin Seidenberg
Frank Küster wrote:

>Benjamin Seidenberg <[hidden email]> 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 or team maintained package?
>>>>
>>>>        
>>>>
>>>Because I don't see how it would be semantically different to the
>>>Maintainer field. The distinction between them is not apparent (what
>>>is Maintainer supposed to mean under this scheme?). And adding new
>>>fields is more work, so you don't do it without a good reason.
>>>
>>>
>>>      
>>>
>>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.
>
>  
>
Right. That was the biggest problem I had with Andrew's idea, he wanted
to use the maintainer field for one person and only one person, who was
a DD. As an applicant, I didn't particularly care for this, and
suggested a "lesser-of-two-evils" approach.

>>The Responsible field would be
>>the one to talk to if the package does something bad from the
>>project's perspective such as a deliberate security issue or it not
>>being up to snuff.
>>    
>>
>
>I don't see why you wouldn't want to talk to the list in this case.  We
>don't need someone to put the blame on (we don't have and don't want any
>"punishment"), rather we need someone to make the necessary changes, be
>it in the package or in the minds of the people who maintain the package.
>
>  
>
*shrug* I agree. At least in my suggestion, you still have the
maintainer field, as opposed to it being a single DD in Andrew's proposal.

>>They would also be the one to talk to if the
>>maintainer or team doesn't respond to other complaints. The maintainer
>>would be the one that users look to on a daily basis - manages bugs,
>>does most of the work, etc.
>>    
>>
>
>I really can't see the difference, neither in a team-maintained package
>nor with an applicant.  In the latter case, of course the sponsor is
>responsible; but even then there's not much point in talking to the
>sponsor if the applicant can just search a new one.
>
>If a package is badly maintained and you get no response, the usual
>procedure is to start with NMUs and proceed with orphaning the package
>(or taking over); where's the difference here between a non-responsive
>single maintainer and a non-responsive team?
>
>  
>
Again, it was my way of tempering Andrew's proposal.

>And in case of complaints about a package, how should someone be able to
>make good decisions if he does *not* receive the messages about it on a
>daily basis, but instead has to dig through them afterwards?  Well,
>there might be rare cases where this is the only way to get an outside
>view of some quarrel, but we already have the TC for this.
>  
>
That was one of my points, under Andrew's proposal, the maintainer would
become a DD and the team/applicant wouldn't recieve these emails.

>  
>
>>Basically, the Responsible field would be what you suggested - a
>>Debian Developer in good standing who offers accountability for the
>>project.
>>    
>>
>
>Ah, so we're going to have two classes of DDs:  The ones with "good
>standing", and the others who are not allowed to be in the Responsible
>field?
>  
>
I would assume all DD's are members in good standing of the project, if
not, shouldn't they be kicked out?

>  
>
>>The Maintainer would be the person or team doing the work,
>>possibly a mailing list or someone who is not a DD. The key is that
>>the Responsible-Person field would add accountability.
>>    
>>
>
>Accountability?  That only makes sense if there are consequences in case
>that person  does bad work.  Either a "criminal action", or some sort of
>private punishment like having to pay money.  All this does not exist in
>Debian, and IMO it doesn't make sense to introduce them.
>
>Regards, Frank
>  
>
Again, this is partly a response to Andrew's proposal of only allowing a
DD as a maintainer and having them as the person where "the buck stops
here". The accountability he wants is the one refered to here.

Cheers,
Benjamin


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

Re: Thoughts on Debian quality, including automated testing

Anthony Towns
In reply to this post by Frank Küster
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* though; having a
team.debian.org webpage or something where such things could be listed
would be lovely.

(So that you can tell if both/all the team is on holidays, if a response
from someone is official, who to try talking to on irc to get an immediate
response, etc; looking through changelogs, or mailing list archives
is okay, but not terribly convenient, especially for team members who
happen not to post a lot, or happen not to upload a lot)

I really hate looking at packages maintained by a list because
I never know who's actually behind it.

(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)

Cheers,
aj


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

Re: Thoughts on Debian quality, including automated testing

Frank Küster
Anthony Towns <[hidden email]> 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 to know who the team actually *is* though; having a
> team.debian.org webpage or something where such things could be listed
> would be lovely.
>
> (So that you can tell if both/all the team is on holidays, if a response
> from someone is official, who to try talking to on irc to get an immediate
> response, etc; looking through changelogs, or mailing list archives
> is okay, but not terribly convenient, especially for team members who
> happen not to post a lot, or happen not to upload a lot)
>
> I really hate looking at packages maintained by a list because
> I never know who's actually behind it.

You are right.  Since I won't have time to setup and advertise a
teams.debian.org webpage, what do people suggest as a short-term
solution?  Should we agree on a standardised file in
/usr/share/doc/<package>, either an item in README.Debian or copyright,
or a separate file TEAM.Debian?

> (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 members, which might
be quite significant contributors and decision makers.

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

Emanuele Rocca
Hello,

* Frank Küster <[hidden email]>, [2005-12-27 10:12 +0100]:
>  Anthony Towns <[hidden email]> 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 members, which might
>  be quite significant contributors and decision makers.

Why would you miss them? AFAIK there is no problem listing non-DD
contributors in the Uploaders fields.

ciao,
    ema

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

Re: Thoughts on Debian quality, including automated testing

Frank Küster
Emanuele Rocca <[hidden email]> wrote:

> Hello,
>
> * Frank Küster <[hidden email]>, [2005-12-27 10:12 +0100]:
>>  Anthony Towns <[hidden email]> 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 members, which might
>>  be quite significant contributors and decision makers.
>
> Why would you miss them? AFAIK there is no problem listing non-DD
> contributors in the Uploaders fields.

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.

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

Moritz Mühlenhoff-2
In reply to this post by Lars Wirzenius-2
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
>       long as they take proper care not to mess the package
>       up.
>
>       (I'm willing to participate in such an experiment
>       myself, but I haven't thought out the details yet.)

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 as long a you send the
patch". Or a free-form field, if that doesn't suffice.

Cheers,
        Moritz


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

Kevin Mark-2
In reply to this post by Anthony Towns
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 solution in the
> > team.
>
> It's nice to know who the team actually *is* though; having a
> team.debian.org webpage or something where such things could be listed
> would be lovely.
Hi AJ,
since there are not a very large number of groups(10<n<100), would it be a good
idea to create a Wiki page for listing teams until it can be resolved
where it should be noted.
cheers,
Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
      `$'         $'        
       $          $                      _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$     $ $$ggggg$ $     $ $ ,$P""  $ $    $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $    $
 `Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $.  ,$.

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

Re: Thoughts on Debian quality, including automated testing

Roger Leigh
In reply to this post by Moritz Mühlenhoff-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moritz Muehlenhoff <[hidden email]> 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 to 0d-NMU for every severity as long a you send the
> patch".

You have to send a patch for all NMUs in any case.  A simple "NMU at
will" tag should be sufficient.  However, a distribution-wide (or
priority-based for base/standard/optional/extra) policy would be
simpler to understand and make use of.

The fact of being group-maintained /should/ make it simpler for
third-party changes to get into a package anyway (since there are more
maintainers to review and commit changes).  This should lessen the
need for 0-day NMUs.


Regards,
Roger

- --
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDsvy4VcFcaSW/uEgRAk2gAKDbPSpXV24YPwaw/9XddKgEqHg5QACeJsej
U7ZmuZIANqprG2Up0ufM0lA=
=dBBq
-----END PGP SIGNATURE-----


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

Lars Wirzenius
In reply to this post by Moritz Mühlenhoff-2
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 as long a you send the
> patch". Or a free-form field, if that doesn't suffice.

I started a list on wiki.debian.org for people who welcome low threshold
NMUs for their packages.

http://wiki.debian.org/LowThresholdNmu

--
When in doubt, use brute force.


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

Lionel Elie Mamane-2
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 to touch this, I bite" to
>> "Feel free to 0d-NMU for every severity as long a you send the
>> patch". Or a free-form field, if that doesn't suffice.

> I started a list on wiki.debian.org for people who welcome low
> threshold NMUs for their packages.

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

--
Lionel


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

Steinar H. Gunderson
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 in before it will let you edit anything.

/* Steinar */
--
Homepage: http://www.sesse.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

Peter Samuelson
In reply to this post by Frank Küster

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

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

Re: Thoughts on Debian quality, including automated testing

Ola Lundqvist
In reply to this post by Thomas Hood-3
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 you do.  You say:
>
> >     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.  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.  Second, putting packages in the custody of a

It really depend on what you mean with an asset. Just because a package
do not have a big userbase do not say that it is unimportant.

To find someone to be named as co-maintainer is quite easy. It is _much_
harder to find a real co-maintainer, that will actually make some work.

If you mean that every package should have at least one other person
that is willing to upload critical fixes, all packages already have that
as all maintainers (or very many of them at least) will NMU packages
if they have RC bugs with a patch... :)

> team makes it easy for a tired maintainer to relinquish control.  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.
>
> 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.  There are several packages in Debian that are

I do not agree, obviously. :)

...CUT...

Regards,

// Ola

--
 --------------------- Ola Lundqvist ---------------------------
/  [hidden email]                     Annebergsslingan 37      \
|  [hidden email]                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------


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

Reply | Threaded
Open this post in threaded view
|

pbuilder testsuite support (Re: Thoughts on Debian quality, including automated testing)

Junichi Uekawa
In reply to this post by Lars Wirzenius-2
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,
>       but it might be that piuparts should run them also.

pbuilder hook is available for those who want to test this framework.


$ mkdir ~/hook
$ cp /usr/share/doc/pbuilder/examples/B92test-pkg ~/hook

add HOOKDIR=/home/XXXX/hook/ to your configuration file

add debian/pbuilder-test/ directory to your source-code.  pbuilder
will use run-parts obtain a list and invoke the shell scripts.  Note
that the current version will refuse to run if debian/pbuilder-test
does not exist; just as a reminder for myself to add a testsuite.


The script is ran inside the chroot and ran as root.
It could be like the following (an example that tests a library package):

002_libecasoundc:
#!/bin/bash

gcc /tmp/buildd/*/debian/pbuilder-test/002_sample.c -o /tmp/002_sample.out $(libecasoundc-config --libs --cflags
)
/tmp/002_sample.out




regards,
        junichi
--
dancer@{debian.org,netfort.gr.jp}   Debian Project


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

Reply | Threaded
Open this post in threaded view
|

A bit of experience after having updated some packages to use pbuilder-test testsuite engine.

Junichi Uekawa
Hi,


> >
> >     * 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,
> >       but it might be that piuparts should run them also.
>
> pbuilder hook is available for those who want to test this framework.

I've been working with this, with a very simplistic set-up of running
multiple shell scripts. There are things that you know beforehand (if
you know the gory details of pbuilder as it is documented).

1. your source code is available in /tmp/buildd/package-version/,
which you can probably match with the wildcard '/tmp/buildd/*/debian/../'

2. your testsuite resides in /tmp/buildd/*/debian/pbuilder-testsuite/*,
which will be executed with run-parts.

3. previous version of your package will be installed by B92test-pkg
by default, from your default apt sources, and if it fails, test won't progress.

4. within the chroot, B92test-pkg by default does the following:
        your previous version is installed from apt sources
        your previous version is removed
        your new package is installed with dpkg -i
this sequence should be improved, and should probably allow failures



Things that I really want to have after testing a few packages.


1. support for common operations, maybe a shell library is in order?
   For example, I usually want to compile/link/execute a test code to
   test a -dev package. That requires some amount of idiom in plain
   shell code, and I shouldn't have to copy-and-paste code all over
   the place.

2. support for providing source data. Most applications eat data and
   output data. I really want some way to provide data and to say
   what's the expected output.

3. support for X. Some of my packages are command-line console tools,
   but many are actually graphical apps. It would be a plus to have
   some kind of interactive/noninteractive X-based testing.




regards,
        junichi
--
dancer@{debian.org,netfort.gr.jp}   Debian Project


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

12345