Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #15530

Re: Suggesting change in DPT policy

From Julian Gilbey <julian@d-and-j.net>
Newsgroups linux.debian.maint.python
Subject Re: Suggesting change in DPT policy
Date 2024-03-01 08:30 +0100
Message-ID <Id5vc-dDFS-11@gated-at.bofh.it> (permalink)
References <Ic0Hf-cWrX-1@gated-at.bofh.it> <Ic6D0-cZX8-11@gated-at.bofh.it> <Ic6D0-cZX8-9@gated-at.bofh.it> <IcawW-d2gs-3@gated-at.bofh.it> <IcUzL-dwql-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Jeroen,

On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote:
> On Tue, 27 Feb 2024 18:32:54 +0000
> Scott Kitterman <debian@kitterman.com> wrote:
> 
> > While I do take advantage of this for a few packages, I don't
> > personally care much either way.  I suspect that packages will be
> > removed from team maintenance as a result though and I think that's
> > a bad idea.
> > 
> > I'd prefer the current approach over people removing packages from
> > the team, so I think it's important that anyone who feels strongly
> > enough about this to do so, speak up.
> 
> For me, the weaker collaboration option that the DPT provides is key
> to putting my packages under a team umbrella.
> 
> As I find myself completely AFK for up to a month at a time for both
> work and private reasons, having a knowledgeable bunch of developers
> around with full access to my packages (VCS and CI included) is a
> definite plus, if only out of a strong sense of responsibility. The
> same goes for benefiting from the shared knowledge of the team,
> including routine fixes and similar minor changes being rolled out
> across all packages in the team.

These are really interesting points.  Under the proposed system, I
presume that one could leave "privately maintained" packages within
the python-team area of salsa and still benefit from these automatic
changes without giving automatic permission to other developers to
make manual changes.  Being part of the team is a relationship between
developers; it surely doesn't say anything about a specific package's
maintenance, just as one can ask questions on debian-devel without
saying "anyone can do anything to my packages without asking me".

> That said, I'm very careful not to spend more time on volunteer
> efforts than I can afford to, and not looking to offload the full
> maintenance of any of my packages. Upstream involvement often gives
> me advance knowledge of upcoming releases, their compatibility issues
> and other quirks, which in turn helps avoid problems on the Debian
> end. I do not share the optimism that documenting such details
> somewhere in individual packages - as suggested elsewhere in this
> thread - would be effective to avoid trouble; more so considering
> that the inability to stick to a single, concise, and rather clear
> team policy is ultimately what triggered this whole discussion in the
> first place.

I don't think it's a binary choice: "offload the full maintenance" of
a package versus "keep the full maintenance".  As far as I understand
it, a package maintained by the team will typically have a main person
who does the day-to-day work on it (few people have the time to start
doing serious work on lots of other packages), but anyone on the team
could work on it.  In the cases mentioned, there are RC bugs in
packages which have not been addressed in a timely fashion and are
holding up transitions or similar.  In some of "my" packages, other
developers on the team have uploaded more regular updates (thanks!).
In most cases, updates are routine and I'm very appreciative of it.

While documenting quirks might not fully avoid trouble, it's much
better than not documenting them.  After all, this is detailed
knowledge of a package or collection of packages that has been gained
over time, and in addition to helping anyone stepping in to do a team
upload, documenting it will help whoever ends up taking over the
package one day (as well as helping the maintainer themselves!).

The question for your quirky packages then becomes: what does the
current team maintenance position offer that having the package solely
maintained by yourself would not provide?  I can see very little;
anyone wanting to help with a package outside of the team can still
offer to do an NMU (and push their changes to salsa).

> As for the inclusion of codes of conduct or similar wording,
> documenting common sense just feels unnecessary. While being on the
> receiving end of a compliment for bug-squashing work is certainly
> nice, the lack thereof isn't a measure of disrespect. I cannot recall
> any discussion on the team's IRC channel or mailing list crossing
> that line.

As far as I understand, this thread was started not because Andreas
did not receive a compliment, but because he received quite unpleasant
emails "telling him off" for doing it.  These were not public
communications, so you would not have seen them.  I don't think anyone
is suggesting that every team upload requires a compliment (though
such things are, of course, nice and appreciated!).

Best wishes,

   Julian

Back to linux.debian.maint.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-27 09:10 +0100
  Re: Suggesting change in DPT policy Scott Talbert <swt@techie.net> - 2024-02-27 15:30 +0100
    Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-27 19:40 +0100
      Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 01:00 +0100
        Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 08:10 +0100
          Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 12:50 +0100
            Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 15:40 +0100
        Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 13:00 +0100
      Re: Suggesting change in DPT policy Jeroen Ploemen <jcfp@debian.org> - 2024-02-29 20:50 +0100
        Re: Suggesting change in DPT policy Julian Gilbey <julian@d-and-j.net> - 2024-03-01 08:30 +0100
          Re: Suggesting change in DPT policy Jeroen Ploemen <jcfp@debian.org> - 2024-03-01 13:10 +0100
            Re: Suggesting change in DPT policy Andreas Tille <tille@debian.org> - 2024-03-02 21:40 +0100
              Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-03-02 22:20 +0100
                Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-03-02 23:20 +0100
                Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-03-03 07:20 +0100
                Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-03-03 18:20 +0100
  +1 (Re: Suggesting change in DPT policy) Jochen Sprickerhof <jspricke@debian.org> - 2024-02-27 15:40 +0100
  Re: Suggesting change in DPT policy Timo Röhling <roehling@debian.org> - 2024-02-27 16:10 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 08:20 +0100
      Re: Suggesting change in DPT policy Étienne Mollier <emollier@debian.org> - 2024-02-28 09:40 +0100
        Maintaining packages with complex relationships (Was: Suggesting  change in DPT policy) Andreas Tille <andreas@an3as.eu> - 2024-02-28 12:00 +0100
          Re: Maintaining packages with complex relationships (Was: Suggesting  change in DPT policy) Timo Röhling <roehling@debian.org> - 2024-02-28 16:50 +0100
  Re: Suggesting change in DPT policy Martin <debacle@debian.org> - 2024-02-27 16:40 +0100
  Re: Suggesting change in DPT policy weepingclown <weepingclown@disroot.org> - 2024-02-27 17:30 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 09:10 +0100
  Re: Suggesting change in DPT policy Arto Jantunen <viiru@debian.org> - 2024-02-27 21:30 +0100
  Re: Suggesting change in DPT policy Louis-Philippe Véronneau <pollo@debian.org> - 2024-02-27 21:40 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 09:30 +0100
      Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 15:30 +0100
        Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 15:50 +0100
  Re: Suggesting change in DPT policy Stefano Rivera <stefanor@debian.org> - 2024-02-28 03:00 +0100
  Re: Suggesting change in DPT policy Agathe Porte <gagath@debian.org> - 2024-02-28 10:30 +0100
  Re: Suggesting change in DPT policy Julian Gilbey <julian@d-and-j.net> - 2024-02-28 11:50 +0100
  Re: Suggesting change in DPT policy Salvo Tomaselli <tiposchi@tiscali.it> - 2024-03-01 01:20 +0100
  Re: Suggesting change in DPT policy Stefano Rivera <stefanor@debian.org> - 2024-03-03 00:10 +0100
  Re: Suggesting change in DPT policy Emmanuel Arias <eamanu@yaerobi.com> - 2024-03-03 00:40 +0100
    Re: Suggesting change in DPT policy Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-03-03 16:20 +0100
  Re: Suggesting change in DPT Policy Nilesh Patra <nilesh@debian.org> - 2024-03-09 18:00 +0100
    Re: Suggesting change in DPT Policy Anton Gladky <gladk@debian.org> - 2024-03-09 18:50 +0100
      Re: Suggesting change in DPT Policy Julian Gilbey <julian@d-and-j.net> - 2024-03-09 22:30 +0100
        Re: Suggesting change in DPT Policy Andreas Tille <andreas@an3as.eu> - 2024-03-19 08:40 +0100

csiph-web