Re: Suggesting change in DPT policy

[Julian Gilbey]

Hi Jeroen,

On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote:
> On Tue, 27 Feb 2024 18:32:54 +
> Scott Kitterman  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

Re: Suggesting change in DPT policy

[Jeroen Ploemen]

On Tue, 27 Feb 2024 18:32:54 +
Scott Kitterman  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.

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.

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.


pgpye0JS70SkC.pgp
Description: OpenPGP digital signature

Re: Request to Join Debian Python Team as a Package Maintainer

[Pulak Bhushan]

Hi Debian Python Team, 


I am following up on my previous request. Could someone please assist
with adding me to th group?

Salsa ID: pulakb

Thank you. 

Regards, 
Pulak Bhushan


On Wed, Feb 21, 2024 at 12:42:33AM +0530, Pulak Bhushan wrote:

Dear Debian Python Team,

I am writing to express my interest in joining the Debian Python Team as a 
package maintainer.

I am interested in joining the Python Team to actively contribute to the 
maintenance of Python-related packages within Debian. I am currently 
maintaining a set of packages (python-pylatex, python-duet, 
python-sphinx-contributors, and python-sphinx-autodoc2) and would like to 
collaborate with the team to bring in more packages to Debian.


My Salsa login is: pulakb

I have thoroughly read the Python Team's policy document, and I accept its 
terms. I am committed to adhering to the guidelines and standards outlined in 
the policy to ensure the smooth functioning of the team and the Debian project 
as a whole.

Thank you for considering my application. I look forward to the opportunity to 
contribute to the Debian Python Team and help enhance the Python ecosystem 
within Debian.

Regards
Pulak Bhushan
pulakbhus...@gmail.com 






signature.asc
Description: PGP signature

Re: O: python-cryptography -- Python library exposing cryptographic recipes and primitives (documentation)

[Jérémy Lal]

Le jeu. 29 févr. 2024 à 12:06, Andreas Tille  a écrit :

> Hi,
>
> as per bug #1064979 python-cryptography was orphaned.  Actually the
> process of orphaninig is defined differently[1] by setting QA team as
> maintainer.  In this case DPT remains maintainer but there is no
> Uploader specified any more.  I personally will not add my ID as
> Uploader.  I have added those team members who did uploads in the last
> year in CC.
>

Good idea since I'm all right with helping to maintain it.
I did the 41 upgrade so I'm already familiar with it.

I'll AMAU unless someone is more motivated.
Source package python-cryptography-vectors needs the same treatment.

I tried to do some bug squashing anyway.  Since the latest version was
> requested in bug #1063771 and this new version also closes #1064778
> (CVE-2024-26130) (the other CVE-bug should have been closed in previous
> upload) I decided to inject latest upstream, adapted the patches and
> pushed to Git.  Unfortunately the package does not build as you can
> verify in Salsa CI[1].

I admit I have no clue how to fix this but I hope someone can take over
> from here.  I guess uploading to experimental first and see how it
> plays nicely with its lots of rdepends makes sense here.


Version 42 needs some rust deps to be updated as well, last time I checked,
and I was in wait-and-see mode about those.

Jérémy

Re: O: python-cryptography -- Python library exposing cryptographic recipes and primitives (documentation)

[Andreas Tille]

Hi,

as per bug #1064979 python-cryptography was orphaned.  Actually the
process of orphaninig is defined differently[1] by setting QA team as
maintainer.  In this case DPT remains maintainer but there is no
Uploader specified any more.  I personally will not add my ID as
Uploader.  I have added those team members who did uploads in the last
year in CC.

I tried to do some bug squashing anyway.  Since the latest version was
requested in bug #1063771 and this new version also closes #1064778
(CVE-2024-26130) (the other CVE-bug should have been closed in previous
upload) I decided to inject latest upstream, adapted the patches and
pushed to Git.  Unfortunately the package does not build as you can
verify in Salsa CI[1].

I admit I have no clue how to fix this but I hope someone can take over
from here.  I guess uploading to experimental first and see how it
plays nicely with its lots of rdepends makes sense here.

Kind regards
Andreas.

PS: I would have expected that to orphan a team maintained package the
team mailing list would have been CCed in the bug report.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package
[2] 
https://salsa.debian.org/python-team/packages/python-cryptography/-/jobs/5381997

-- 
http://fam-tille.de