Hi Julian,
Am Sat, Mar 09, 2024 at 09:21:40PM +0000 schrieb Julian Gilbey:
> Following on from some earlier discussions, I've been thinking about
> the relationship between the DPT (presumably a group of developers who
> work together) and salsa (could there be packages in the
> python-team/packages area which are not team maintained?). I reread
> much of the policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and discovered something quite strange. The introduction begins:
>
> ---
> [Old version stripped]
> ---
>
> If the DPT is a team (a group of maintainers/developers/helpful
> others), what does "The DPT is hosted at salsa" mean - how can a
> "team" be hosted? (And in the first paragraph, "maintained by a team"
> seems a little strange too.)
>
> Perhaps something like the following would be better (shifting the
> focus from the tools to the people), and would also separate concerns
> more clearly:
I like this shift.
> ---
> Introduction:
>
> The Debian Python Team (DPT) is a group of maintainers who are jointly
> responsible for a large number of Python packages in Debian. They
> package and support available Python modules and applications that may
> be useful.
>
> By using a central location on salsa.debian.org, the Debian GitLab
> instance, for these team-maintained packages, the DPT are able to
> improve responsiveness, integration, and standardization.
> ---
I think it makes sense if you create some MR for the suggested change.
> Then the details of how to mark a package as being team-maintained can
> be left to the Maintainership section.
>
> We could then include a statement along the lines of the following
> (though I'm not sure where would be best):
>
> ---
> Python module packages which are not team-maintained by the DPT can
> also be stored in the python-team/packages namespace on salsa in order
> to benefit from the integration and standardization tools such as
> Janitor. Manual changes to these packages by someone other than the
> package's maintainer should be proposed via salsa merge requests or
> comments in the BTS (or using NMUs if appropriate) as for any other
> individually-maintained package.
> ---
I see the advantage of having all Python packages in a common name space
on Salsa. However, I fail to see the advantage of individually
maintained packages in Debian in general. The discussion here did not
really contained arguments convincing me about the need for individual
maintainership. Well, for sure we have maintainers of very high
competence for specific packages and it is good to consult these before
doing some upload.
The suggsted solution was to add some debian/README.to_be_decided_ext.
I confirm that bumping to a new upstream version might be harmful in
certain cases and there are packages where this should not be done
without confirmation of one of the persons specified in the Uploaders
field. To my experience these packages are an exception - most packages
that where lagging behind upstream are harmless.
In general I would consider it sensible that *any* team member has
permission to
1. Add autopkgtest
2. Fix bugs (no matter about severity)
3. Fix lintian issues
4. Upload Janitor changes
by doing
dch --team
marked cangelog entry. We have made good experiences with this (not
even written) policy in Debian Med. Well, in real practice it does not
happen *that* frequently that maintainers have so much time and energy
to crawl the package pool seeking for chances of enhancements (even if I
wished this would be the case). Thus I suggest to lower the barrier to
do so to a sensible minimum. Adding some
debian/README.to_be_decided_ext (debian/README.source which is
established and documented) mentioning potential pitfalls should be
sufficient to warn a team member driven by good intentions (and I assume
this is the case for any team member).
> It would be good to say something about Uploaders in the
> Maintainership section. Perhaps something like this:
>
> ---
> A package maintained within the team must have the name of the team in
> the Maintainer field:
>
> Maintainer: Debian Python Team <team+pyt...@tracker.debian.org>
>
> This enables the team to have an overview of its packages on the
> DDPO_website.
>
> If a particular developer wishes to take primary responsibility for a
> package, they should put their name in the Uploaders field. [*** What
> does this mean though? Maybe something like: In this case, any DPT
> member is still welcome to make changes to the package, though it is
> polite to contact the developer(s) named in the Uploaders field
> first. ***]
To my experience an Uploader does not respond to say some RC bug due to
time constraints. Asking and waiting for a time constrained person
might be just another ping that drains time from this person. For sure
the some imagined bug report in question might just be overlooked and
such a ping might trigger immediate responce. On the other hand I
experienced that it just involves another waiting period and is slowing
down the process of getting things fixed. There are chances that the
slice of spare time of the other contributor is running out before the
Uploader might have time to respond. Thus IMHO we should not express
the need for contacting another team member explicitly and rather
trust common sense and some debian/README.* .
To the contrary: If a team member intends to care for some specific
package in the long run, the ID should be simply added to the Uploaders
field. Its a list and I'd prefer if we would have more than one
elements in this list for every important package. For sure it makes
sense to inform other Uploaders once someone might add the own ID.
Finally we are talking about good communication practices between
contributors.
> If there are complications in the packaging of the module, for
> example, if certain modules are interdependent and need to be updated
> together, this should be documented in debian/README.source [*** or
> somewhere else ***]
> ---
I think if we draft some MR about this document we should probably
start by suggesting debian/README.source.
Finally I'm wondering what the decision making process about team policy
might be. OK, we have some MRs. Do we need some confirmation comments?
Currently there are 9 MRs[1] some created 5 years ago with latest
changes two years ago[2] (the update 2 years ago was a question why this
is still open).
>From my (probably biased) perspective MR "Drop option of weak
collaboration and permit DPT team as Maintainer only"[3] which is discussed
in this thread received
1. Lots of positive responses
2. a) Some doubts by Scott
b) No response from Pjotr
(Scott and Pjotr are listed as project members in
python-team/tools/python-modules so have commit permissions)
3. Some kind of "silent disagreement" by Sandro
4. LGTM after some enhancements by Eberhard
How do we proceed from here now?
Kind regards
Andreas.
[1] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests
[2] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/7
[3]
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
[4] https://salsa.debian.org/python-team/tools/python-modules/-/project_members
--
http://fam-tille.de
