Gioele Barabucci <gioele@svario.it> writes:
> Hi,
>
> an alternative that I was thinking of, is making this "everybody is
> onboard" policy more explicit by having a special email to use for the
> Maintainer field. For example:
>
> Maintainer: Debian community <debian-community@lists.debian.org>
>
> The stewards of the package could be listed as Uploaders, as it
> currently happens with team-maintained packages.
>
> Lintian would then raise an error (not overridable for uploads) if the
> Maintainer field is not set to a @{lists,tracker}.debian.org email AND
> debian/dont_touch_my_package is not present with some text in it.
>
> This would mimic what some maintainers are already doing today:
> orphaning a package (i.e., setting its Maintainer address to
> packages@qa.debian.org), moving themselves to the Uploaders field and
> then carrying on maintaining the package as part of the "QA Team"
> (everybody is part of the QA Team...).
I like universally maintained packages, the collaborate athmosphere in
the Go team has been a nice change of working on packaging for me, and
it seems there are other groups in Debian that work like that too.
I've long though about changing maintainer to QA for my packages like
you suggest, but there has been at least on reason I haven't done so:
lack of clear effective written down team policy in what the conventions
are. I don't know what the packaging and upload policies are for
'Maintainer: Debian QA Team'. It seems some people orphan their
packages to use the QA team, which I find a strange approach.
The https://go-team.pages.debian.net/ pages may have some flaws, but one
key social function is that it establishes the group as a team effort.
That goal is something to take after. I'm trying migrate my
pkg-auth-maintainers packages to pkg-security just because
https://wiki.debian.org/Teams/pkg-security establish the same social
function, that we never managed to create within pkg-auth-maintainers.
I'm now learning Python team conventions --
https://wiki.debian.org/Python/LibraryStyleGuide -- too, and find
similar elements.
These policies are mutually incompatible and each is opinonated about
its own technical choices, but I find adapting to a set of consistency
rules helps collaborative work, regardless of what those technical
choices are.
So what I'm trying to say is: I'm +1 on using a "global" Debian
developer Maintainer: field as a way of signalling that the people
working on that package are open for any developer to make changes to
the Salsa git repository and make package uploads, as a way to help the
package forward -- but that this messaging is combined with some written
down conventions that may evolve over time. Referring to the DEP
standards may be sufficient for now. I see problems with GitLab but
today I don't really see any alternative to using salsa.debian.org for
all such joint development work. Having packaging on Salsa and
accepting contributions via Salsa is desirable. That doesn't mean you
cannot have it elsewhere too, even a master git repository, but the
social function of having packages available for contributions on Salsa
is a good one.
/Simon
Attachment:
signature.asc
Description: PGP signature