Re: Suggesting change in DPT policy
Am Tue, Feb 27, 2024 at 04:25:49PM + schrieb weepingclown: > While perfectly understanding the weak collaboration model reasoning, I've > still always found DPT as uploader and not maintainer rather absurd TBH. The > current go to tool (as I understand it) for python packaging, py2dsp, also > creates an initial packaging with team in uploaders section and the person as > maintainer; something that I find even more absurd. Not only would I welcome > this suggested change, I also think it is better if py2dsp default to > starting with DPT as maintainers. Good point. I've filed #1064952 pypi2deb: Please set DPT as Maintainer and the ID of the person calling py2dsp as uploader with a patch that works for me in one test example. The interesting thing is that a tool targeting at streamlining the work of DPT is not team maintained itself. It is maintained by those two maintainers who obviously see some value in the weak cooperation option udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 20; maintainer | count -+--- Piotr Ożarowski |23 Sandro Tosi |82 (2 rows) which might influence their decision of the design of the tool. Kind regards Andreas. [1] https://bugs.debian.org/1064952 -- http://fam-tille.de
Re: Suggesting change in DPT policy
Hi, Louis-Philippe (just quoting below in case you might have missed it) is repeating the importance that anyone who thinks my suggestion (MR[1]) is a bad idea make themselves heard. I'm hereby adding those maintainers who have more than 5 packages that are affected and did not yet raised their opinion in To: field. udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 5; maintainer| count -+--- Debian PaN Maintainers | 7 Jeroen Ploemen |16 Piotr Ożarowski |23 Sandro Tosi |82 Scott Kitterman| 7 Vincent Bernat |15 (6 rows) Debian PaN is another team which might need extra discussion but I think the intention is clear and Scott has raised his opinion before[2]. Kind regards Andreas. [1] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20 [2] https://lists.debian.org/debian-python/2024/02/msg00060.html Am Tue, Feb 27, 2024 at 03:36:24PM -0500 schrieb Louis-Philippe Véronneau: > On 2024-02-27 03:05, Andreas Tille wrote: > > Hi, > > > > I became more deeply involved into DPT since 2022 as a consequence of > > the suggestion for transfering several Debian Med/Science packages to > > DPMT[1][2]. I happily followed this suggestion and moved >30 packages > > from the Blends teams to DPT. I was happy with this move since it makes > > sense. > > > > Recently we received lots of testing removal warnings in those Blends > > teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So > > I did what I usually do in those teams: I dedicated quite some time in > > team wide bug hunting. That way I squashed about 50 bugs on packages > > where I was not in Uploaders. When doing so I usually run > > routine-update on the package which basically streamlines packaging to > > latest standards including calling Janitor tools which are so far > > accepted inside DPT. > > > > I probably should have reviewed the DPT policy on Maintainership[3] more > > carefully. In other teams, it's common for the Maintainer to be set to > > the team, so I assumed it was just an oversight when I made this > > change[4] when touching the package to fix RC bug #1058177. However, I > > I was pointed immediately about the fact that I was mistaken according > > to the current DPT policy. I apologize for this. However, the wording > > of the comment on my commit was discouraging, especially considering I > > was a volunteer who had fixed a critical bug. Because of this, I > > decided to focus my efforts on fixing other critical bugs for the > > moment. If the comment had started with a 'Thanks for fixing the > > critical bug, but...' I likely would have corrected my mistake quickly. > > The lack of respect from my teammate simply made me prioritize my time > > on other issues that are more visible to our users. I wonder whether I > > should propose another change to the policy about maintaining a kind and > > polite language inside the team - but that's a different thing. > > > > While I applied the patch for another RC bug (#1063443) after >2 weeks > > which triggered a RC bug in reportbug I remembered the "keep the > > maintainer" policy. But I kept on doing Janitor like changes since > > finally the package is maintained in a team where Janitor is accepted. > > When doing so I failed the phrase "please contact the Maintainer for the > > green light." I apoligize for this again. The response was another > > volunteer-demotivating private mail (thus no quote) which also was > > lacking the "Thanks for fixing"-phrase and degrading my changes as > > "frivolous". > > > > So far what happened (seen from my possibly biased perspective). > > > > Why do I like to change the policy? > > > > The current wording provides some means to stop volunteer team members > > helping out moving forward to speed up migrations and fix Debian wide > > dependencies. It hides team maintained packages from a common BTS > > view. When pointing my browser to > > https://bugs.debian.org/team+pyt...@tracker.debian.org > > I currently see 1339 open bugs (calculated by [UDD1]). This hides > > another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work > > around this flaw I used an UDD query to find relevant Python3.12 bugs. > > > > When I think twice about the wording > > Team in Uploaders is a weak statement of collaboration.[3] > > I personally consider it a statement of *no* collaboration (which fits > > the wording of the responses I've got). > > > > How can a team member for instance f
Re: Suggesting change in DPT policy
Hi all, Andreas Tille, on 2024-02-28: > Am Tue, Feb 27, 2024 at 04:08:51PM +0100 schrieb Timo Röhling: > > I guess the motivation behind the weak collaboration model is that some > > packages have hidden "gotchas", which a casual team uploader might not know. > > For instance, pygit2 is one of multiple libgit2 language bindings which all > > need to be upgraded in lock-step when a new upstream version is released. > > You are making an important point here. Thanks Timo for raising this point, it is important indeed. > > Instead of restricting collaboration, we could let policy encourage > > maintainers to state such constraints in debian/README.DPT and ask team > > members to check that file before they team-upload. > > I think this is a very good idea. In case MR[1] will be accepted this > should be added to the policy as well. I'm not sure whether the > "Maintainership" paragraph is the best place to add this. I wonder if > you (or someone with the same doubts) might want to suggest another MR > to add this debian/README.DPT feature. Policy changes aside, I think it could be useful for the routine-update command to stop when such file is hit, in order to raise the importance that the package has quirks, and should not be casually updated without involved scrutiny. I wonder whether this can be generalized, like if d/README.source file is present? (Although the latter use is codified[2] and I'm not confident it is 100% suitable for such purpose: I see many such files on my radar which do not necessarily hint for quirks.) Of course this could be overred with a --readme-reviewed flag once ready to finalize the package with automation for instance. > [1] > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20 [2]: https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Dream the Electric Sleep - Utopic signature.asc Description: PGP signature
Re: Suggesting change in DPT policy
Hello, I support this change too. I am myself set to maintainer of packages just because whatever tool we used at the time to generate debian/ directory for a package did that. On 2024-02-28 09:21, Andreas Tille wrote: Hi, Louis-Philippe (just quoting below in case you might have missed it) is repeating the importance that anyone who thinks my suggestion (MR[1]) is a bad idea make themselves heard. I'm hereby adding those maintainers who have more than 5 packages that are affected and did not yet raised their opinion in To: field. udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 5; maintainer| count -+--- Debian PaN Maintainers | 7 Jeroen Ploemen | 16 Piotr Ożarowski |23 Sandro Tosi | 82 Scott Kitterman| 7 Vincent Bernat | 15 (6 rows) Debian PaN is another team which might need extra discussion but I think the intention is clear and Scott has raised his opinion before[2]. Kind regards Andreas. [1] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20 [2] https://lists.debian.org/debian-python/2024/02/msg00060.html Am Tue, Feb 27, 2024 at 03:36:24PM -0500 schrieb Louis-Philippe Véronneau: On 2024-02-27 03:05, Andreas Tille wrote: Hi, I became more deeply involved into DPT since 2022 as a consequence of the suggestion for transfering several Debian Med/Science packages to DPMT[1][2]. I happily followed this suggestion and moved >30 packages from the Blends teams to DPT. I was happy with this move since it makes sense. Recently we received lots of testing removal warnings in those Blends teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So I did what I usually do in those teams: I dedicated quite some time in team wide bug hunting. That way I squashed about 50 bugs on packages where I was not in Uploaders. When doing so I usually run routine-update on the package which basically streamlines packaging to latest standards including calling Janitor tools which are so far accepted inside DPT. I probably should have reviewed the DPT policy on Maintainership[3] more carefully. In other teams, it's common for the Maintainer to be set to the team, so I assumed it was just an oversight when I made this change[4] when touching the package to fix RC bug #1058177. However, I I was pointed immediately about the fact that I was mistaken according to the current DPT policy. I apologize for this. However, the wording of the comment on my commit was discouraging, especially considering I was a volunteer who had fixed a critical bug. Because of this, I decided to focus my efforts on fixing other critical bugs for the moment. If the comment had started with a 'Thanks for fixing the critical bug, but...' I likely would have corrected my mistake quickly. The lack of respect from my teammate simply made me prioritize my time on other issues that are more visible to our users. I wonder whether I should propose another change to the policy about maintaining a kind and polite language inside the team - but that's a different thing. While I applied the patch for another RC bug (#1063443) after >2 weeks which triggered a RC bug in reportbug I remembered the "keep the maintainer" policy. But I kept on doing Janitor like changes since finally the package is maintained in a team where Janitor is accepted. When doing so I failed the phrase "please contact the Maintainer for the green light." I apoligize for this again. The response was another volunteer-demotivating private mail (thus no quote) which also was lacking the "Thanks for fixing"-phrase and degrading my changes as "frivolous". So far what happened (seen from my possibly biased perspective). Why do I like to change the policy? The current wording provides some means to stop volunteer team members helping out moving forward to speed up migrations and fix Debian wide dependencies. It hides team maintained packages from a common BTS view. When pointing my browser to https://bugs.debian.org/team+pyt...@tracker.debian.org I currently see 1339 open bugs (calculated by [UDD1]). This hides another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work around this flaw I used an UDD query to find relevant Python3.12 bugs. When I think twice about the wording Team in Uploaders is a weak statement of collaboration.[3] I personally consider it a statement of *no* collaboration (which fits the wording of the responses I've got). How can a team member for instance find anot
Re: Suggesting change in DPT policy
Hi, 2024-02-27 09:06 CET, Andreas Tille: > I probably should have reviewed the DPT policy on Maintainership[3] more > carefully. In other teams, it's common for the Maintainer to be set to > the team, so I assumed it was just an oversight when I made this > change[4] when touching the package to fix RC bug #1058177. However, I > I was pointed immediately about the fact that I was mistaken according > to the current DPT policy. I also have been bitten by this recently. I assumed that the package was DPT maintained because it was in the DPT namespace on Salsa. But it was not. And I got a message after my upload. If the package was outside of DPT, I would have created a bug instead for the maintainer to handle. I do not understand the point of Uploader: DPT compared to individually maintained packages. So, +1 for this.
Re: Suggesting change in DPT policy
On 2/28/24 00:54, Scott Kitterman wrote: It's self-induced. I mean if it's demotivating to have people point out that you didn't follow the policy, then you can solve that all by yourself by following the policy. If I take your argument to its logical conclusion, all of Debian's rules can be demotivating when people ignore them, so we should get rid of them all so your feelings are safe. The way you're wording it, it feels like we on purpose didn't follow what was written in the policy. That's not the case. The point you're missing here, is that this policy is not obvious at all, and it's easy to either not understand it, or not know about it. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 2/28/24 09:21, Andreas Tille wrote: Hi, Louis-Philippe (just quoting below in case you might have missed it) is repeating the importance that anyone who thinks my suggestion (MR[1]) is a bad idea make themselves heard. I'm hereby adding those maintainers who have more than 5 packages that are affected and did not yet raised their opinion in To: field. udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 5; maintainer| count -+--- Debian PaN Maintainers | 7 Jeroen Ploemen | 16 Piotr Ożarowski |23 Sandro Tosi | 82 Scott Kitterman| 7 Vincent Bernat | 15 (6 rows) Note that it's been the case at least for Vincent, in at least a few instances, that the tooling (py2dsp you wrote?) made him wrongly put the team as uploader. There's porbably other cases as well. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On Tue, Feb 27, 2024 at 09:05:44AM +0100, Andreas Tille wrote: > Hi, > > [...] +1 from me, too. I had completely forgotten this paragraph in the Python policy and it doesn't make that much sense. I personally generally do send an email to anyone in the "Maintainers" field or the last uploader just as a matter of courtesy before working on something, and then wait for a day before doing anything; for all I know, they may already be working on a patch, especially if it's a very new bug. But if the model of team maintainership is made much stronger and clearer, though I would still encourage sending an email to the "main maintainer" for anything non-trivial, even if just to let them know the situation. In response to other comments, I suggest that those maintainers who do not wish other team members to help work on their packages under this new approach should just remove DPT from the Maintainer and Uploader fields, and regard any offers of help as an NMU or merge request. One tweak to Andreas's patch: > diff --git a/policy.rst b/policy.rst > index 27bf6f3..7185d6d 100644 > --- a/policy.rst > +++ b/policy.rst > @@ -48,20 +48,14 @@ Maintainership > == > > A package maintained within the team should have the name of the team either this should be: - A package maintained within the team should have the name of the team either + A package maintained within the team should have the name of the team > -in the ``Maintainer`` field or in the ``Uploaders`` field. > +in the ``Maintainer``. Best wishes, Julian
Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)
Hi Étienne, Am Wed, Feb 28, 2024 at 09:37:59AM +0100 schrieb Étienne Mollier: > > > Instead of restricting collaboration, we could let policy encourage > > > maintainers to state such constraints in debian/README.DPT and ask team > > > members to check that file before they team-upload. > > > > I think this is a very good idea. In case MR[1] will be accepted this > > should be added to the policy as well. I'm not sure whether the > > "Maintainership" paragraph is the best place to add this. I wonder if > > you (or someone with the same doubts) might want to suggest another MR > > to add this debian/README.DPT feature. > > Policy changes aside, (Thus changed subject. ;-) ) > I think it could be useful for the > routine-update command to stop when such file is hit, in order > to raise the importance that the package has quirks, and should > not be casually updated without involved scrutiny. I wonder > whether this can be generalized, like if d/README.source file is > present? (Although the latter use is codified[2] and I'm not > confident it is 100% suitable for such purpose: I see many such > files on my radar which do not necessarily hint for quirks.) > > Of course this could be overred with a --readme-reviewed flag > once ready to finalize the package with automation for instance. I like all your suggestions. When reading Timo's suggestion about debian/README.DPT I also thought about rather using the more generic debian/README.source. In any case I agree that routine-update should respect such debian/README.* (except debian/README.Debian which is user oriented). I admit I like this kind of constructive discussion. Kind regards Andreas. > > [1] > > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20 > [2]: > https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source -- http://fam-tille.de
Re: Suggesting change in DPT policy
On February 28, 2024 7:08:14 AM UTC, Andreas Tille wrote: >Hi Scott, > >Am Tue, Feb 27, 2024 at 11:54:01PM + schrieb Scott Kitterman: >> It's self-induced. I mean if it's demotivating to have people point out >> that you didn't follow the policy, then you can solve that all by yourself >> by following the policy. If I take your argument to its logical conclusion, >> all of Debian's rules can be demotivating when people ignore them, so we >> should get rid of them all so your feelings are safe. > >I agree that it was my mistake to not follow team policy. I should not >have done this and I apologized for this. I should have written this >e-mail first to change a policy that does not fit my experiences in >other teams as well as what obviously several contributors consider >inappropriate. To solve this I started this discussion and meanwhile >created a MR[1]. > >The demotivating part was the wording to point me to the policy. I >addressed this with the words "I wonder whether I should propose another >change to the policy about maintaining a kind and polite language inside >the team - but that's a different thing." in my initial mail[2]. > >To make sure this will really clear I added the proposed change in a >second MR[3] containing the following diff: This makes more sense to me. It is completely understandable that how things are communicated affects how people feel about them. This is a difficult thing to get right. I have experienced similar demotivating conversations in Debian myself. Everyone in Debian is already bound by the code of conduct already, so it seems redundant to add it here again. While I agree with the principle you are trying to address, I think this change unnecessarily clutters the DPT document and we should not make it. Scott K
Re: Suggesting change in DPT policy
On February 28, 2024 9:54:55 AM UTC, Thomas Goirand wrote: >On 2/28/24 00:54, Scott Kitterman wrote: >> It's self-induced. I mean if it's demotivating to have people point out >> that you didn't follow the policy, then you can solve that all by yourself >> by following the policy. If I take your argument to its logical conclusion, >> all of Debian's rules can be demotivating when people ignore them, so we >> should get rid of them all so your feelings are safe. > >The way you're wording it, it feels like we on purpose didn't follow what was >written in the policy. That's not the case. > >The point you're missing here, is that this policy is not obvious at all, and >it's easy to either not understand it, or not know about it. That seems rather tangential to the question at hand. In the cases you cited the people in question both knew about and understood the policy. I agree that I am not really following your logic. Andreas' explanation makes more sense to me, but it's neither here nor there as you don't need to convince me. My only concern is that we not cause people to leave the team over this change. I'm personally ambivalent about it. Scott K
Bug#1064959: ITP: python-usb-devices -- Python tools for mapping, describing, and resetting USB devices
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-usb-devices Version : 0.4.5 Upstream Author : J. Nick Koston * URL : https://github.com/bluetooth-devices/usb-devices * License : MIT Programming Lang: Python Description : Python tools for mapping, describing, and resetting USB devices A comprehensive toolkit for interacting with USB and Bluetooth devices in Python. Offering functionally to map USB device connections, describe device attributes, and perform device reset operations. . Ideal for developers aiming to integrate USB device management into their projects, it supports asynchronous programming paradigms and is designed to work seamlessly with modern Python async features. I plan to maintain this package as part of the Python team.
Re: Suggesting change in DPT policy
On Wednesday, February 28, 2024 3:21:12 AM EST Andreas Tille wrote: > Hi, > > Louis-Philippe (just quoting below in case you might have missed it) is > repeating the importance that anyone who thinks my suggestion (MR[1]) is > a bad idea make themselves heard. I'm hereby adding those maintainers > who have more than 5 packages that are affected and did not yet raised > their opinion in To: field. > > udd=> SELECT * FROM (select maintainer, count(*) from sources where > uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group > by maintainer order by maintainer) tmp WHERE count > 5; maintainer > | count > -+- > -- Debian PaN Maintainers > | 7 > Jeroen Ploemen |16 > Piotr Ożarowski |23 > Sandro Tosi |82 > Scott Kitterman | 7 > Vincent Bernat |15 > (6 rows) > > Debian PaN is another team which might need extra discussion but I think > the intention is clear and Scott has raised his opinion before[2]. > > Kind regards > Andreas. > > [1] > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/ > 20 [2] https://lists.debian.org/debian-python/2024/02/msg00060.html I used to use this a lot more than I do now. Currently I only use it for packages where I'm also the or a upstream developer, so it generally makes more sense to do non-packaging changes there. This did cause me to go back and check and I found one I had missed when I was changing this previously. I've just uploaded vrfydmn with DPT as maintainer. Looking at your list, I note that it includes team members that have been very active in team wide work, not just on their own packages. I think it would be contrary to the spirit of Debian and working together if we changed the rules and they felt they had to leave the team. Scott K signature.asc Description: This is a digitally signed message part.
Re: Suggesting change in DPT policy
Hi Scott, Am Wed, Feb 28, 2024 at 11:44:07AM + schrieb Scott Kitterman: > > This makes more sense to me. It is completely understandable that how things > are communicated affects how people feel about them. This is a difficult > thing to get right. I have experienced similar demotivating conversations in > Debian myself. Seems everybody who has contributed to Debian some time was facing this. > Everyone in Debian is already bound by the code of conduct already, so it > seems redundant to add it here again. While I agree with the principle you > are trying to address, I think this change unnecessarily clutters the DPT > document and we should not make it. I have no really strong opinion about this. I had the cluttering point in mind when I moved this paragraph right to the end. I agree that it is redundant to some extend. Sometimes saying things repeatedly does not harm but I would not strongly insist on this change. Kind regards Andreas. -- http://fam-tille.de
Re: Suggesting change in DPT policy
Hi Scott, Am Wed, Feb 28, 2024 at 09:19:29AM -0500 schrieb Scott Kitterman: > Looking at your list, I note that it includes team members that have been > very > active in team wide work, not just on their own packages. I'm fully aware of this. > I think it would be > contrary to the spirit of Debian and working together if we changed the rules > and they felt they had to leave the team. It is not my intention to move anybody out of the team but find some consensus that other teams in Debian agreed upon as well. Kind regards Andreas. -- http://fam-tille.de
Re: Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)
Hi, * Andreas Tille [2024-02-28 11:51]: I think it could be useful for the routine-update command to stop when such file is hit, in order to raise the importance that the package has quirks, and should not be casually updated without involved scrutiny. I wonder whether this can be generalized, like if d/README.source file is present? (Although the latter use is codified[2] and I'm not confident it is 100% suitable for such purpose: I see many such files on my radar which do not necessarily hint for quirks.) I like all your suggestions. When reading Timo's suggestion about debian/README.DPT I also thought about rather using the more generic debian/README.source. In any case I agree that routine-update should respect such debian/README.* (except debian/README.Debian which is user oriented). I also thought of README.source at first, and I remained on the fence until Étienne brought up the potential use for routine-update, which makes me think that a dedicated "quirks" file makes more sense. I'm not too attached to the .DPT suffix though, maybe something like README.team or even README.quirks signals the intention behind the file even better. I'll leave the bikeshedding to interested readers for now. :) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Suggesting change in DPT policy
On 2/28/24 12:44, Scott Kitterman wrote: Everyone in Debian is already bound by the code of conduct already, so it seems redundant to add it here again. I agree. Thomas
python3-poetry-dynamic-versioning is now in the Debian archive
Hello! python3-poetry-dynamic-versioning recently landed in the archive and I wanted to make it known! This package does something similar to python3-setuptools-scm and can be used in Debian in a similar way. You can use it manually with the following snippet, but pybuild's next release will automate this [1]. - export POETRY_DYNAMIC_VERSIONING_BYPASS = $(DEB_VERSION_UPSTREAM) include /usr/share/dpkg/pkg-info.mk - With the rise of poetry as a packaging tool, I think it'll become more and more common. There is already a bunch of packages in the archive that could use it :) https://codesearch.debian.net/search?q=poetry-dynamic-versioning+path%3Apyproject.toml&literal=0 Cheers! [1]: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/54 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
RM: nb2plots -- ROM; leaf package
control: tag -1 +moreinfo Hi, I'm using this (nice, alive...) package and I'm willing to maintain it in the Python Team. Greetings, Alexandre
