Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
that policy is well written down, at https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin - give it a look and see if it clarifies your doubt about team maintenance and why someone would prefer to have the ultimate responsibility for the quality of a package. you already created the openstack team (which is great!) with exactly and only the rules you like, where you're free to do what you feel is best; that's great but please also realize not everyone shares the same ideas as yours and you should try sometimes to respect those people decisions too. On Mon, Nov 11, 2019 at 6:14 PM Thomas Goirand wrote: > > On 11/11/19 9:17 PM, Scott Kitterman wrote: > > Personally, I've been judicious in putting myself as Maintainer in DPMT and > > PAPT packages. If we were to ditch the current policy, my immediate > > response would be to remove DPMT/PAPT from uploaders and maintain them > > outside the team. It's about 1/4 of my DPMT/PAPT packages. > > > > I suspect I'm not the only one. > > > > Your proposal is not cost free for the teams. > > > > Scott K > > Hi Scott, > > Exactly what difference would it make? Just that your package would > really appear as not team-maintained, which is already the current plain > reality (as the "unwritten policy" tells nobody else but you can touch > the package). So I don't see why anyone in the team would mind. > > Cheers, > > Thomas Goirand (zigo) > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
On 11/11/19 9:17 PM, Scott Kitterman wrote: > Personally, I've been judicious in putting myself as Maintainer in DPMT and > PAPT packages. If we were to ditch the current policy, my immediate response > would be to remove DPMT/PAPT from uploaders and maintain them outside the > team. It's about 1/4 of my DPMT/PAPT packages. > > I suspect I'm not the only one. > > Your proposal is not cost free for the teams. > > Scott K Hi Scott, Exactly what difference would it make? Just that your package would really appear as not team-maintained, which is already the current plain reality (as the "unwritten policy" tells nobody else but you can touch the package). So I don't see why anyone in the team would mind. Cheers, Thomas Goirand (zigo)
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
On November 10, 2019 10:09:57 PM UTC, Thomas Goirand wrote: >On 11/10/19 1:20 AM, Sandro Tosi wrote: >> is there any public trace of these "many voices"? > >Just like when we discussed moving away from SVN to Git, we can't know >the exact number unless we have a kind of poll/vote (but we don't >actually *have* to start such poll... I'm just saying it's hard to know >otherwise). > >However, I can account for maybe 5 people (it's hard to remember) who >told me (face to face) they hate this policy, and it felt like there >was >a broad consensus that it was really against a team spirit, plus it >made >little sense to have a package team maintained with strong ownership. I >wouldn't name the persons I have in mind publicly, because they haven't >granted me the permission to do so, and therefore, it wouldn't be nice >to do so. > >All of this is just feelings I had during conversations with others, >and >of course, cannot be accounted as just plain facts, so just take it as >it is: just a report of the feeling I had when talking with others, >that >it looks like I'm far from the only one disliking this policy because >of >the above mentioned reasons. > >As Louis-Philippe wrote, it's very much ok to delay this conversation, >but sooner or later, it will come back on the table. Personally, I've been judicious in putting myself as Maintainer in DPMT and PAPT packages. If we were to ditch the current policy, my immediate response would be to remove DPMT/PAPT from uploaders and maintain them outside the team. It's about 1/4 of my DPMT/PAPT packages. I suspect I'm not the only one. Your proposal is not cost free for the teams. Scott K
Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, thank you very much for taking the time to review the packaging and providing such detailed and helpful feedback. On 10.11.19 00:02, Nick Morrott wrote: > Thank you for your work in packaging python-pyjsparser. Out of > curiosity, what are you using to be build your package? My primary motivation for packaging python-pyjsparser is to be able to bump the version of Charliecloud: https://tracker.debian.org/pkg/charliecloud Version 0.10 of Charliecloud adds new dependencies, including lark-parser which in turn depends on python-js2py which in turn depends on python-pyjsparser. > I checked out the package and built it - your work looks good, and the > build was successful. I then ran it through lintian, Debian's package > linting tool which you should get into the habit of using before > uploading to salsa (and once you're a DM/DD, also before uploading to > the archive). I have configured my sbuild setup in such a way that it always runs lintian after builds. But thanks to your feedback I noticed that I was running lintian with a too high display threshold such that the only lintian feedback I received was "I: Lintian run was successful." and "Lintian: pass" despite of the issues you discovered. I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I will not miss similar issues in the future. > * d/control > - no Rules-Requires-Root field [lintian] Fixed. > - the extended package description should probably include details > about the library's key features/support [lintian] Done. > * d/copyright > - the only copyright dates I can see in the source are 2014-2015 Judging from the source files, you are right. Judging from the git commit history I see commits between 2015 and 2019. What is a better guideline for copyright years: copyright notices in the source or the git history? Maybe it would be best to combine both information which would yield 2014-2019. Once I know what should be used, I will update the copyright file accordingly. > - you can add the Upstream-Contact field to the header Done. > * d/rules > - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1" Added. > * d/upstream/metadata > - please add and complete this file - there are plenty of examples > in the team's salsa project [lintian] Done. > * d/watch > - +1 for asking upstream to version their releases on github Thanks! Let's see what happens. > - the additional (commented) scaffolding inserted into the file by > dh-make can be removed to leave only the version line and the URL to > check [lintian] The idea behind leaving the Github lines as comment was that I could easily switch to following Github tags/releases provided that upstream decides to publish them for future releases. But since the "" string triggers the lintian complaint and replacing this placeholder would be just guessing until upstream actually provides releases on Github, I removed all comments related to this. This also makes lintian happier. :-) > - as this is a version 4 watch file, we can take advantage of new > variable substitutions for the version and extension fields, so that > the URL to check would look like: > > https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@ Very convenient variables. Changed accordingly. > * upstream changelog > - there is no upstream changelog To my knowledge upstream does not provide such a file. > * documentation/examples > - There is no documentation at all, aside from the simple example in > the README. Perhaps this snippet could be installed as an example when > installing the package? Done (although I am not sure whether the way I implemented it is the recommended way to do it). Suggestions how to improve the code are welcome. > * tests > - there are no tests to run at build time (and therefore no > autopkgtests to run for continuous integration whenever the package's > dependencies are updated). Looking at the github repo there seems to > be a significant testsuite that should really be available in the > Debian source package to take advantage of autopkgtest. [lintian] The testsuite available on Github requires js2py which is not in the Debian archive yet (thus the testsuite introduces a circular dependence: pyjsparser <-> js2py). js2py is the next package on my to-package list (see above). I see two options to move forward: 1. Wait for js2py being packaged and provide autopkgtests for pyjsparser once js2py is available. 2. Install js2py using pip for the test. None is really nice in my opinion. Which option do you prefer? > I hope you find this useful - if you have any questions don't hesitate > to ask the team (the Python list is visible and archived, IRC may get > a quicker answer...). I'm a new DD and there are likely some things > that the more experienced members of the team will notice. Yes, your feedback was definitely very helpful and allowed me to learn new things. Thanks, Peter
Re: Severity bump script
On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy wrote: > > Hi Sandro, > > -- Forwarded message - > > We are going to raise the severity of the py2removal bugs to "serious" in > > several steps. In the > > first phase we are going to raise severity of the py2removal bugs for > > all leaf module packages and low popcon (< 300) application packages. > > Bugs marked with the "py2keep" user tag will not have their severity > > raised. > > is there any progress with script from your site please? First we need list > to check. Thanks a lot. no progress on this yet. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
On 11/11/19 9:21 AM, Fabrice BAUZAC-STEHLY wrote: > For the record, it looks like this policy comes from the package > "developers-reference", section "Collaborative maintenance". Absolutely not. The developers-reference doesn't tell what the Python team policy is when the Uploaders field contains the team address. It only tells that it is possible to do that, not what it implies in our team. Cheers, Thomas Goirand (zigo)
Re: Python 2 removal in sid/bullseye: Progress and next steps
Hi, po 11. 11. 2019 v 12:07 odesílatel Yves-Alexis Perez napsal: > generic question about the interaction between the python transition and > current situation with NEW processing. > I think it's unrelated. State of NEW processing is stable for long time. But if you need to accept NEW binary-only I think it's fine to ping ftp-masters over IRC. I already did this few times and they don't bite :) -- Best regards Ondřej Nový
Re: Python 2 removal in sid/bullseye: Progress and next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-11-11 at 12:04 +0100, Matthias Klose wrote: > > sorry if this has been discussed already somewhere else (I stopped reading > > - -devel@ a long time ago) but is there something done to improve NEW > > processing > > here? I have two package sitting there because of the introduction of a > > - -python3 binary package. I don't think it's really make sense to remove > > python2 stuff if python3 stuff can't enter the archive… > > well, at least you can name the packages in your email ... Hi Matthias, the packages are libimobiledevices and libplist but this mail wasn't specific about my packages (or I would have contacted ftpmasters list) but rather a generic question about the interaction between the python transition and current situation with NEW processing. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3JQL4ACgkQ3rYcyPpX RFuEzQf/X2eaVjrjP1dMKHEhTz9Ez6fCjSEKDlHC5XfsFb4AmtPhkvUUBdeczmO0 aC6+m9Izpsr0c6Vr52GXbSrZsaAtEB93+4FkDMwt2FvXQEi+Azvl9Hub5jAJx7WT ocinEEQVgP2d4vxAs8ROY86Qm77nVKJ4jMw35Sjxvw1HNrA9fgIepk+0b9XA0Kxf f5GOvb1fxnEjy6L5zqYQMRkdTrGvoRFLMjWxAwLj/VpWadr3jXBrObtIbCV4Lywk DIlJ56mnMz9u12i35U0ccwXYvlHSCI9g9V99JWWLJdAEXG8Pi1tcv935XkFuyXAz jXCaUlLik64/FK7YkIrBS2WtmudViQ== =V+3N -END PGP SIGNATURE-
Re: Python 2 removal in sid/bullseye: Progress and next steps
On 11.11.19 11:43, Yves-Alexis Perez wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-11-11 at 10:33 +0100, Ondřej Nový wrote: We are going to raise the severity of the py2removal bugs to "serious" in several steps. In the first phase we are going to raise severity of the py2removal bugs for all leaf module packages and low popcon (< 300) application packages. Bugs marked with the "py2keep" user tag will not have their severity raised. If nobody fixes that bug, the packages will be auto-removed from testing. We will also then file bug reports against ftp.debian.org to remove such packages from unstable. We are going to do this semi- automatically as additional packages become leaf packages. Hi, sorry if this has been discussed already somewhere else (I stopped reading - -devel@ a long time ago) but is there something done to improve NEW processing here? I have two package sitting there because of the introduction of a - -python3 binary package. I don't think it's really make sense to remove python2 stuff if python3 stuff can't enter the archive… well, at least you can name the packages in your email ...
Re: Python 2 removal in sid/bullseye: Progress and next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-11-11 at 10:33 +0100, Ondřej Nový wrote: > We are going to raise the severity of the py2removal bugs to "serious" > in several steps. In the > first phase we are going to raise severity of the py2removal bugs for > all leaf module packages and low popcon (< 300) application packages. > Bugs marked with the "py2keep" user tag will not have their severity > raised. If nobody fixes that bug, the packages will be auto-removed > from testing. > We will also then file bug reports against ftp.debian.org to remove > such packages from unstable. We are going to do this semi- > automatically as additional packages become leaf packages. Hi, sorry if this has been discussed already somewhere else (I stopped reading - -devel@ a long time ago) but is there something done to improve NEW processing here? I have two package sitting there because of the introduction of a - -python3 binary package. I don't think it's really make sense to remove python2 stuff if python3 stuff can't enter the archive… Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3JO2EACgkQ3rYcyPpX RFvT6QgAoc0t3/jqSqvd21TExKaD5cfAapJva9/pjABOX//ZUOF4WFgbmfeOso3h Qz3spQJgrxMYc1R6EZYVi6qlMesH4uDmKaGhfskaVvIL640k7OxMy9taXXBOW2N9 4Sn6ILPqwLp6OmDJxg9I5jIkxJE+VlLJzvJderbEueu67sulD3pCyA6E1HQGqB2R S7f0YHVEnAhBDmChZBCXtrChZwt/DHwAQlI/Ud4OlNVyHTKdl37myqk+Es5S/8vL VO0zyIgiyLhLyQJsw9gTrGkl4aXFQhIfcyzGUgOvQredQb9airhJCTU+djVShk7Y neEVMDF30IBRwyepKMJG8OYOJ8O1tQ== =6uw7 -END PGP SIGNATURE-
Re: Policy About Maintainer and Uploaders Fields
Would it be possible to satisfy both groups by having an option on DDPO and similar listing tools for "only show team-as-Maintainer packages" vs "also show team-as-Uploader packages"? i.e. making it convenient for people to use either of these definitions of "in the team" as they prefer?
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
For the record, it looks like this policy comes from the package "developers-reference", section "Collaborative maintenance". -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
