Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Packaging team best practice (http://www.linux-archive.org/debian-development/149072-packaging-team-best-practice.html)

Noah Slater 08-26-2008 12:54 PM

Packaging team best practice
 
Hello,

I have been having some discussion with a member of the Erlang packaging team
about best practice and comparing this with the Python Modules packaging team.

The two teams approach things slightly differently...

Python Modules

* The focus is on individual maintainership

* Uploaders is always set to the team email address

* Maintainer is generally set to the email address of the primary person
maintaining the package even though as a team the package is sometimes
edited by other people

* The entire team's packages can be seen using:

http://qa.debian.org/developer.php?login=python-modules-team@lists.alioth.debian.org

* Example package, sponsored upload:

http://packages.qa.debian.org/p/python-couchdb.html

Erlang:

* The focus is on collaborative maintainership

* Uploaders is always set to the developer(s) uploading/sponsoring the package

* Maintainer is generally set to the team address for the core packages even
though only certain members of the team may be actively maintaining it

* Maintainer is set to the email address of the primary person maintaining the
package for non-core packages even though as a team the package is sometimes
edited by other people

* Consequentially, only some of the packages can be seen using:

http://qa.debian.org/developer.php?login=erlang-pkg-devel@lists.berlios.de

* Example core package, non-sponsored upload:

http://packages.qa.debian.org/e/erlang.html

* Example non-core package, sponsored upload:

http://packages.qa.debian.org/c/couchdb.html

Clearly some teams will organise differently, and that's fine, but it would be
nice if we could agree a set of guidelines for using the Maintainer/Uploaders
fields consistently across teams.

This would, at least, make using the Quality Assurance reports more useful.

The closest thing I could find to a set of packaging team guidelines is:

http://wiki.debian.org/Teams/Guidelines

Nothing is mentioned in relation to this issue.

Thoughts? Feedback? Am I missing some existing documentation?

Many thanks,

--
Noah Slater, http://bytesexual.org/nslater


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Norbert Preining 08-26-2008 01:40 PM

Packaging team best practice
 
On Di, 26 Aug 2008, Noah Slater wrote:
> Clearly some teams will organise differently, and that's fine, but it would be
> nice if we could agree a set of guidelines for using the Maintainer/Uploaders
> fields consistently across teams.

I disagree. Teams work differently and thus the Maintainer/Uploader
usage differs. What is the problem.

Leave the teams to work out what is best for them, and do not regulate
it. It does not increase productivity, nor security, nor acceptance,
only regulation annoyances.

Best wishes

Norbert
Debian TeX Team ;-)

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BRYMBO
The single unappetising bun left in a baker's shop after four p.m.
--- Douglas Adams, The Meaning of Liff


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Sandro Tosi" 08-26-2008 01:47 PM

Packaging team best practice
 
Hi Noah,

On Tue, Aug 26, 2008 at 14:54, Noah Slater <nslater@bytesexual.org> wrote:
> Hello,
>
> I have been having some discussion with a member of the Erlang packaging team
> about best practice and comparing this with the Python Modules packaging team.
>
> The two teams approach things slightly differently...
>
> Python Modules
>
> * The focus is on individual maintainership
>
> * Uploaders is always set to the team email address
>
> * Maintainer is generally set to the email address of the primary person
> maintaining the package even though as a team the package is sometimes
> edited by other people

This is not entirely true: each one can choose to set maintainer as
the team or a "real person"; for example, take a look to every module
I package[1] in the team: the Maintainer field is always set to the
team.

Additionally, this was already discussed some time back[2].

> Erlang:
[ ... 8< ... ]

Well, you can even cite the perl team, with a different policy[3]

> Clearly some teams will organise differently, and that's fine, but it would be
> nice if we could agree a set of guidelines for using the Maintainer/Uploaders
> fields consistently across teams.
>
> This would, at least, make using the Quality Assurance reports more useful.
>
> The closest thing I could find to a set of packaging team guidelines is:
>
> http://wiki.debian.org/Teams/Guidelines
>
> Nothing is mentioned in relation to this issue.

I think I'm not seeing the issue here: some team can even just provide
a "common place to store package", a "wing" under which maintainer can
keep the package.

> Thoughts? Feedback? Am I missing some existing documentation?

Well, I think that teams are composed by people with a common intent,
so if those people agreed on a process to maintaint package, so let it
be.

I don't know if "imposing" something would come out with a better
situation than the actual one.

Cheers,
Sandro

[1] http://qa.debian.org/developer.php?login=matrixhasu@gmail.com
[2] http://lists.debian.org/debian-python/2008/03/msg00014.html
[3] http://pkg-perl.alioth.debian.org/policy.html

--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Noah Slater 08-26-2008 02:32 PM

Packaging team best practice
 
On Tue, Aug 26, 2008 at 03:47:55PM +0200, Sandro Tosi wrote:
> This is not entirely true: each one can choose to set maintainer as the team
> or a "real person"; for example, take a look to every module I package[1] in
> the team: the Maintainer field is always set to the team.

I see, that's very similar to how the Erlang team are doing it.

> I think I'm not seeing the issue here:

Maybe I misrepresented my self in the original email, I don't see a MAJOR issue
with the status quo, nor do I feel that anything should be imposed on the
existing teams. I was more hoping for feedback on the reasons for the subtly
different ways of using the Maintainer/Uploaders fields within the context of a
packaging team with a view to codifying some best practices.

On Tue, Aug 26, 2008 at 03:40:53PM +0200, Norbert Preining wrote:
> On Di, 26 Aug 2008, Noah Slater wrote:
> > Clearly some teams will organise differently, and that's fine, but it would
> > be
> > nice if we could agree a set of guidelines for using the
> > Maintainer/Uploaders
> > fields consistently across teams.
>
> I disagree. Teams work differently and thus the Maintainer/Uploader usage
> differs. What is the problem.

>From some of the private conversations I have had I am aware that some people do
not feel it is appropriate to list a team's email address in the Uploaders field
under any circumstances and others probably feel the same way about the
Maintainer field. Having some community guideline that says what is and isn't
okay either way would be nice, even if it just says "do whatever."

Best,

--
Noah Slater, http://bytesexual.org/nslater


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Noah Slater 08-26-2008 02:41 PM

Packaging team best practice
 
On Tue, Aug 26, 2008 at 03:32:25PM +0100, Noah Slater wrote:
> From some of the private conversations I have had I am aware that some people
> do not feel it is appropriate to list a team's email address in the Uploaders
> field under any circumstances and others probably feel the same way about the
> Maintainer field. Having some community guideline that says what is and isn't
> okay either way would be nice, even if it just says "do whatever."

Along these lines, we have this from the thread you cited:

http://lists.debian.org/debian-python/2008/03/msg00016.html

This is exactly the kind of thing (ignoring the correctness of Piotr's personal
policy which I don't feel qualified to comment on either way) that would be
useful as a codified set of best practices.

Best,

--
Noah Slater, http://bytesexual.org/nslater


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

gregor herrmann 08-26-2008 09:18 PM

Packaging team best practice
 
On Tue, 26 Aug 2008 13:54:09 +0100, Noah Slater wrote:

> Clearly some teams will organise differently, and that's fine, but it would be
> nice if we could agree a set of guidelines for using the Maintainer/Uploaders
> fields consistently across teams.

There were two BOFs at DebConf about team-maintainance of packages,
which also talked about the Maintainer/Uploaders topic.

The minutes of the BOFs are available at
http://lists.debconf.org/lurker/message/20080815.023943.bf7a5f27.en.html
http://lists.debconf.org/lurker/message/20080817.235345.667b162b.en.html

I'm going to post a summary of the BOFs here on -devel as soon as I
have adapted to Europe agin (just came home from .ar an hour ago).

Cheers,
gregor
--
.'`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
: :' : debian gnu/linux user, admin & developer - http://www.debian.org/
`. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
`- NP: The Doors: Waiting For The Sun


All times are GMT. The time now is 01:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.