Re: [DPMT] radical changes: automation, carrot and stick
[Piotr Ożarowski, 2015-10-02] > * adding a package to the team (and getting all benefits, like > sponsoring, bug fixes, etc.) requires pushing at least one commit to > package without member's name in debian/control a month > (doesn't matter if it's a typo fix, RC bug fix or a tag which can > be made only by those who upload/sponsor packages from now on) s|without member's name in debian/control|without member's name in Maintainer| (to make sure people will not be afraid to add themselves to Uploaders) the idea stays the same: contrary where Debian is unfortunately going right now, increase maintainer's strong feeling of responsibility for given package > * removal¹ of packages (not person) from the team if there's no > contribution in 3 months in a row (and given person is not MIA, as in > active in other packages, for MIA ones: decide if someone wants to > take over or orphan the package, no more team packages that nobody > takes care of and no objections if someone takes over your package) rephrased: * removal¹ of packages (not person) from the team if there's no contribution in 3 months in a row and no other team wants to take over given package -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: PGP signature
Re: I've been removed from the Python team
❦ 1 octobre 2015 18:48 -0400, Scott Kitterman : > For the git migration, the people taking the time to do the work or pay > attention to the work and provide feedback are driving what happens > when. It's not possible to give feedback or help when we don't know anything about the migration. I have asked about it several times [0] and got no answer. I only know that Stefano is doing or will do the migration. I don't know if there are difficulties, I don't know if there is opposition or simply if he doesn't have time right now. [0]: <87h9mc79fv@zoro.exoscale.ch> <87k2swh0l6@zoro.exoscale.ch> > With the exception of the DPL, Debian is not democratic. It's doacratic. > Let's not mess with that. Unfortunately, in a _team_, we cannot do as we please. Thomas did try and was kicked. He also maintains a lot of Python packages in pkg-openstack and is seen as a bad team player by several members. He did propose several times to help with the Git migration but never got acknowledged. I am glad and grateful that some people are involved in this Git migration but as a team member, I would also be glad to be kept posted about it. -- Use data arrays to avoid repetitive control sequences. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: [DPMT] radical changes: automation, carrot and stick
❦ 2 octobre 2015 09:41 +0200, Piotr Ożarowski : > * removal¹ of packages (not person) from the team if there's no > contribution in 3 months in a row and no other team wants to take over > given package 3 months is quite short. I have packages that don't get updates that often. This should be couple to debian/watch to know if there is some new upstream release. -- Writing is turning one's worst moments into money. -- J.P. Donleavy signature.asc Description: PGP signature
Re: [DPMT] radical changes: automation, carrot and stick
[Vincent Bernat, 2015-10-02] > ❦ 2 octobre 2015 09:41 +0200, Piotr Ożarowski : > > > * removal¹ of packages (not person) from the team if there's no > > contribution in 3 months in a row and no other team wants to take over ^ + member > > given package > > 3 months is quite short. I have packages that don't get updates that > often. This should be couple to debian/watch to know if there is some > new upstream release. it's 3 months to contribute to other packages (the ones where you're not listed in Maintainer). If you think we'll run out of bugs shortly this way, check this page¹ and if you want to be a member of the team and do nothing for the team in 3 months, then why do you want to be part of it? [¹] https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=python-modules-t...@lists.alioth.debian.org -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: PGP signature
Re: [DPMT] radical changes: automation, carrot and stick
❦ 2 octobre 2015 10:30 +0200, Piotr Ożarowski : >> ❦ 2 octobre 2015 09:41 +0200, Piotr Ożarowski : >> >> > * removal¹ of packages (not person) from the team if there's no >> > contribution in 3 months in a row and no other team wants to take over >> > given package >> >> 3 months is quite short. I have packages that don't get updates that >> often. This should be couple to debian/watch to know if there is some >> new upstream release. > > it's 3 months to contribute to other packages (the ones where you're not > listed in Maintainer). > If you think we'll run out of bugs shortly this way, check this page¹ > and if you want to be a member of the team and do nothing for the team > in 3 months, then why do you want to be part of it? OK, I understand. I always add myself as uploader before making a non-trivial change (to be able to receive bug reports outside the team mailing list). I understand it will be accounted for a contribution in this case, right? -- The first thing we do, let's kill all the lawyers. -- Wm. Shakespeare, "Henry VI", Part IV signature.asc Description: PGP signature
Re: [DPMT] radical changes: automation, carrot and stick
On 2015-10-02 at 10:19:10 +0200, Vincent Bernat wrote: > ❦ 2 octobre 2015 09:41 +0200, Piotr Ożarowski : > > * removal¹ of packages (not person) from the team if there's no > > contribution in 3 months in a row and no other team wants to take over > > given package > 3 months is quite short. I have packages that don't get updates that > often. This should be couple to debian/watch to know if there is some > new upstream release. +1: I also have packages that get new upstream releases very rarely (<1 per year): they are not dead, just very stable and with limited scope, so there is no need to work often on them. -- Elena ``of Valhalla''
Re: [DPMT] radical changes: automation, carrot and stick
[Vincent Bernat, 2015-10-02] > OK, I understand. I always add myself as uploader before making a > non-trivial change (to be able to receive bug reports outside the team > mailing list). I understand it will be accounted for a contribution in > this case, right? right. The easiest contribution would be to sponsor an upload -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: [DPMT] radical changes: automation, carrot and stick
[Elena ``of Valhalla'', 2015-10-02] > +1: I also have packages that get new upstream releases very rarely (<1 > per year): they are not dead, just very stable and with limited scope, > so there is no need to work often on them. well, then you will not gain much from maintaining this package within a team (and let me repeat it again: commiting something in package where you're listed as main contact / main responsible person - doesn't count) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
get started with building own packages
Hi, I would like to see the python based software "privacyIDEA" http://privacyidea.org (2-factor-authentication) in Debian. And I am willing to put some effort into it - since I am the author ;-) It is written in flask and requires additional packages, which are not available in Jessie, yet: * python-flask-cache * python-pymysql * python-pyjwt (Makes 3 more packages) It needs to run as a web service via wsgi. I would also like to add a meta package, that takes care of setting up the database and the web server. (Those packages already exist for Ubuntu Trusty - but I am _very_ sure there will be much discussions about the package quality ;-) What do you think about this? About the meta package idea? Should I start with all 4-5 packages immediately? I guess I have to start with a RFP/ITP. Is there anyone, who might sponsor such packages? Thanks for your response and kind regards Cornelius -- Cornelius Kölbel cornelius.koel...@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel signature.asc Description: This is a digitally signed message part
Re: [DPMT] radical changes: automation, carrot and stick
[Piotr Ożarowski, 2015-10-02] > * removal¹ of packages (not person) from the team if there's no > contribution in 3 months in a row and no other team wants to take over > given package or a warning after month of inactivity and team removal from all packages if number_of_commits_in_a_year / 12 < 1 (and seriously, sponsoring 1 package each month or reviewing a patch from BTS and commiting it is not that much to ask, I know we're all volunteers but one cannot just dump packages on us and contribute nothing back) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: get started with building own packages
On Fri, Oct 02, 2015 at 12:54:47PM +0200, Cornelius Kölbel wrote: > It is written in flask and requires additional packages, which are not > available in Jessie, yet: > > * python-flask-cache > * python-pymysql This one exists in sid (and in jessie-backports). > * python-pyjwt This one exists even in jessie. > It needs to run as a web service via wsgi. > I would also like to add a meta package, that takes care of setting up > the database and the web server. I'm not sure why do you need a separate package for this. > I guess I have to start with a RFP/ITP. ITP. -- WBR, wRAR
Re: [DPMT] radical changes: automation, carrot and stick
On 2015-10-02 at 11:28:04 +0200, Piotr Ożarowski wrote: > [Elena ``of Valhalla'', 2015-10-02] > > +1: I also have packages that get new upstream releases very rarely (<1 > > per year): they are not dead, just very stable and with limited scope, > > so there is no need to work often on them. > well, then you will not gain much from maintaining this package within a > team I don't keep those packages in the team because I expect to get help with them, I keep them there because I believe that by following the team rules they can be of higher quality or at least more consistent with other similar packages and thus better for those users who want to do something with the package other than simply installing it. I could maintain those package elsewhere while still following the team rules, but is there a point doing it? > (and let me repeat it again: commiting something in package where you're > listed as main contact / main responsible person - doesn't count) I've only received your second message after I've sent mine, sorry, and I misunderstood what the actual proposal in that poing was. -- Elena ``of Valhalla''
Re: RFS updating the setuptools-scm and mistune packages
On Wed, 30 Sep 2015 at 13:55 Julien Puydt wrote: > ssh://git.debian.org/git/python-modules/packages/mistune.git > ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git > Uploaded.
Re: get started with building own packages
Am Freitag, den 02.10.2015, 16:15 +0500 schrieb Andrey Rahmatullin: > On Fri, Oct 02, 2015 at 12:54:47PM +0200, Cornelius Kölbel wrote: > > It is written in flask and requires additional packages, which are not > > available in Jessie, yet: > > > > * python-flask-cache > > * python-pymysql > This one exists in sid (and in jessie-backports). > > * python-pyjwt > This one exists even in jessie. Oh, cool. I missed this. This helps. > > > It needs to run as a web service via wsgi. > > I would also like to add a meta package, that takes care of setting up > > the database and the web server. > I'm not sure why do you need a separate package for this. At the moment I have a package privacyidea-apache2 and privacyidea-nginx, which both require python-privacyidea, the webserver, database... > > I guess I have to start with a RFP/ITP. > ITP. > Thanks for your feedback! Kind regards Cornelius signature.asc Description: This is a digitally signed message part
Re: RFS updating the setuptools-scm and mistune packages
Le vendredi 02 oct. 2015 à 11:23:57 (+), Tristan Seligmann a écrit : > On Wed, 30 Sep 2015 at 13:55 Julien Puydt wrote: > > > ssh://git.debian.org/git/python-modules/packages/mistune.git > > ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git > > > > Uploaded. Thanks! Snark on #debian-python
Re: I've been removed from the Python team
On October 2, 2015 4:14:19 AM EDT, Vincent Bernat wrote: >❦ 1 octobre 2015 18:48 -0400, Scott Kitterman : > >> For the git migration, the people taking the time to do the work or >pay >> attention to the work and provide feedback are driving what happens >> when. > >It's not possible to give feedback or help when we don't know anything >about the migration. I have asked about it several times [0] and got no >answer. I only know that Stefano is doing or will do the migration. I >don't know if there are difficulties, I don't know if there is >opposition or simply if he doesn't have time right now. > >[0]: <87h9mc79fv@zoro.exoscale.ch> > <87k2swh0l6@zoro.exoscale.ch> > >> With the exception of the DPL, Debian is not democratic. It's >doacratic. >> Let's not mess with that. > >Unfortunately, in a _team_, we cannot do as we please. Thomas did try >and was kicked. He also maintains a lot of Python packages in >pkg-openstack and is seen as a bad team player by several members. He >did propose several times to help with the Git migration but never got >acknowledged. > >I am glad and grateful that some people are involved in this Git >migration but as a team member, I would also be glad to be kept posted >about it. I think everything I know about it, I learned from either this list or IRC, so I'd recommend a review of the list archive. There's a wiki page somewhere as well. AIUI, there's still some issues with the migration script, but I don't know the details either. Personally, I'd like a better feel for when it'll be ready, but I don't imagine barry or tumbleweed actual know. Scott K
Re: I've been removed from the Python team
[Scott Kitterman, 2015-10-02] > There's a wiki page somewhere as well. main Python page (https://wiki.debian.org/Python) points to https://wiki.debian.org/Python/GitPackaging -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: get started with building own packages
Am Freitag, den 02.10.2015, 16:02 +0200 schrieb Paul Wise: > On Fri, Oct 2, 2015 at 1:48 PM, Cornelius Kölbel wrote: > > > At the moment I have a package > > > > privacyidea-apache2 and privacyidea-nginx, > > which both require python-privacyidea, the webserver, database... > > An alternative might be to depend on httpd, dbcommon-config and then > on package install, detect which web server is available, prompt the > sysadmin for the relevant config info and generate the relevant web > server and application configuration. > Ah, so apache2 and nginx provide httpd. I was not aware of this. Thanks! Cornelius signature.asc Description: This is a digitally signed message part
Re: get started with building own packages
On Fri, Oct 2, 2015 at 1:48 PM, Cornelius Kölbel wrote: > At the moment I have a package > > privacyidea-apache2 and privacyidea-nginx, > which both require python-privacyidea, the webserver, database... An alternative might be to depend on httpd, dbcommon-config and then on package install, detect which web server is available, prompt the sysadmin for the relevant config info and generate the relevant web server and application configuration. -- bye, pabs https://wiki.debian.org/PaulWise
Git migration schedule
I know there's been a lot of questions about the schedule for the git migration. Right now, Stefano is at PyconZA, so he hasn't had much time to follow up here. But he and I discussed a schedule for the migration, and we're sharing it now both so you know what's going on and so we have to stick to it . Flag day: 9-Oct 5-Oct - Do one last test run with an updated svn dump. Put the results in a public place for folks to play with and comment on. 8-Oct - Assuming no objections or showstoppers, turn off write access to all of DPMT svn. 9-Oct - One more svn dump and conversion run. Move the git repos into their final resting place. Announce, celebrate, ???, profit! Remember that the page describing how things will work within the team once we've migrated to git is described here: https://wiki.debian.org/Python/GitPackaging We'll make that page official once the migration is done. The code implementing the migration is here: git://git.debian.org/users/stefanor/dpmt-migration.git Cheers, -Barry (and Stefano) pgpsTA62a5lj4.pgp Description: OpenPGP digital signature
Re: [DPMT] radical changes: automation, carrot and stick
On Oct 02, 2015, at 11:28 AM, Piotr Ożarowski wrote: >well, then you will not gain much from maintaining this package within a >team It's not just the maintainer that wins by maintaining the package within the team. The team also wins because it is now empowered to fix problems when the need arises. That's what being in a team is about - I can help when I have the need, time, interest, and ability, and you can do the same, within the established and agreed upon rules. That's the heart of collaboration. We've explored the downsides, but I think it's important to also recognize the upsides to being in a team. Let's not optimize for the worst case scenario. It's good that this thread reiterated the expected best practices for team members -- and we should do that periodically to remind old-timers and inform newcomers. Who else remembers those old Usenet group monthly FAQs that used to get posted? Cheers, -Barry
Re: get started with building own packages
On Fri, Oct 2, 2015 at 4:04 PM, Cornelius Kölbel wrote: > Ah, so apache2 and nginx provide httpd. I was not aware of this. Yes, along with a lot of other web servers. You could also just depend on apache2 | nginx since there is no way to generate configuration for all web servers and you probably don't want to spend time doing that yourself. -- bye, pabs https://wiki.debian.org/PaulWise
Re: get started with building own packages
Am Freitag, den 02.10.2015, 16:39 +0200 schrieb Paul Wise: > On Fri, Oct 2, 2015 at 4:04 PM, Cornelius Kölbel wrote: > > > Ah, so apache2 and nginx provide httpd. I was not aware of this. > > Yes, along with a lot of other web servers. You could also just depend > on apache2 | nginx since there is no way to generate configuration for > all web servers and you probably don't want to spend time doing that > yourself. > Wait, let me think about this... ...No! signature.asc Description: This is a digitally signed message part
Re: Searching for a roundup sponsor
On Oct 01 2015, "Kai Storbeck" wrote: > Hi, > > Roundup 1.4.20-1.1 is still the version in stable. Roundup 1.5 was > released a few years back, and I need someone to help me with the > final stages in getting 1.5 in stretch, or getting it removed. > > > Roundup is a python web application with quite some vendored code > (javascript libs and fonts), 5 different licenses, and in 1.5.0 there > is an offending file that has an incompatible licensing, so I had to > "dfsg" it. (is there a verb for that?) > > During this work a security issue came along and this made me realise > that the architecture of roundup isn't exactly compatible with what I > would expect from a proper Debain package. > > We can create security updates for roundup, but that won't help any > existing user as all actual issue trackers are using a copy of the lib > at the time of their birth. > > I'm quite unsure on how to proceed here, but perhaps someone with more > experience can help me with the steps needed. I'd suggest to patch the roundip initialization command to use symlinks to /usr instead of copying the libs. Disclaimer: it's been a while since I last used roundup, and much longer since I last set up a fresh instance. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: [DPMT] radical changes: automation, carrot and stick
On Oct 02 2015, Piotr Ożarowski wrote: > I think that the main problem of our team is that we have over 300 > members and only few people contribute to packages they didn't inject to > the repo (some people do not care even about those). I always assumed that it was generally preferred to have Python packages be maintained in the Python team, even if the maintainer has little interest or time in contributing to other Python packages. Did I get the wrong impression? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: [DPMT] radical changes: automation, carrot and stick
On Friday, October 02, 2015 09:12:44 AM Nikolaus Rath wrote: > On Oct 02 2015, Piotr Ożarowski wrote: > > I think that the main problem of our team is that we have over 300 > > members and only few people contribute to packages they didn't inject to > > the repo (some people do not care even about those). > > I always assumed that it was generally preferred to have Python packages > be maintained in the Python team, even if the maintainer has little > interest or time in contributing to other Python packages. > > Did I get the wrong impression? Not from my perspective. I'm in the middle of doing the transition that adds python3.5 as a supported python3 version right now and I've done several team uploads of things that I would have had to wait on an NMU for if the package wasn't in the team. I would certainly prefer to see more packages in the team rather than fewer. Scott K
Re: [DPMT] radical changes: automation, carrot and stick
On Friday, October 02, 2015 01:18:00 AM Piotr Ożarowski wrote: > I think that the main problem of our team is that we have over 300 > members and only few people contribute to packages they didn't inject to > the repo (some people do not care even about those). I think this is in part because we have a culture that discourages this. I do it, but only, as a rule, for packages that have DPMT set as maintainer. > Here are some ideas on how to change that: > * team only in Uploaders field, the main contact (AKA Maintainer) has to > be real person (reason: nobody reads -team mailing list) + automatic > team subscription via script that sets up git repository Personally, I like the current approach where someone can either commit to either strong team maintainership (DPMT in maintainer) or weak team involvement (DPMT as uploader). If you'll check, I have done both and it reflects my level of interest in the package. If I'm maintainer, absent urgent things like RC bug fixes, I expect to know about things before they go in the archive (delayed or not). I do read the list as the bugs come in. I don't necessarily try and deal with all of them, but I do tackle them as i have time. I wish more people would do this, but changing the DPMT to uploader isn't going to help that. Even if more people get bug mail, we can't make them read it. > * when someone who is not listed in debian/control (i.e. > Maintainer/Uploaders) wants to upload team package - just commit > and upload to DELAYED/2 (in case of RC bug) or to DELAYED/7, no need > to notify anyone, because... I think for RC issues, just upload. For non-RC issues, I don't think just uploading, even to delayed is OK. > * emails with all commits (diffs) made by someone not listed in Maintainer > are automatically sent to Maintainer I like this idea, although I think it's OK to limit it to mailing diffs by someone neither in uploaders nor maintainer. In cases where I have active co- maintainers in uploaders, there's no need to mail their commits to me as I trust them. BTW, don't forget that once we switch to git, the repos will be full source, not just /debian so these diffs could get large. > * adding a package to the team (and getting all benefits, like > sponsoring, bug fixes, etc.) requires pushing at least one commit to > package without member's name in debian/control a month > (doesn't matter if it's a typo fix, RC bug fix or a tag which can > be made only by those who upload/sponsor packages from now on) I think any sponsor can ask people do this now. We don't need a rule. > * automatic emails with a warning if there's more than 31 days since the > last contribution described above > * removal¹ of packages (not person) from the team if there's no > contribution in 3 months in a row (and given person is not MIA, as in > active in other packages, for MIA ones: decide if someone wants to > take over or orphan the package, no more team packages that nobody > takes care of and no objections if someone takes over your package) Personally, I would find this kind of rule demotivating. I think it will actually discourage participation which isn't what we want. > I can implement all scripts that automate above tasks but someone > will have to replace me in the admin seat. > > [¹] as in upload to unstable without DPMT in Uploaders, repo stays in > case one decides come back I liike some of your suggestions. I definitely agree with the goal of trying to get more people working on a team wide basis. Scott K signature.asc Description: This is a digitally signed message part.
Re: Git migration schedule
On Fri, Oct 2, 2015 at 3:24 PM, Barry Warsaw wrote: > 5-Oct - Do one last test run with an updated svn dump. Put the results in a > public place for folks to play with and comment on. > > 8-Oct - Assuming no objections or showstoppers, turn off write access to all > of DPMT svn. those are not many days to review the results of the conversions: can you (or Stefano) share what were the problems that delayed the transition, so that we can check in particular those aspects of the packages we know the most? -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: Git migration schedule
On Oct 02, 2015, at 09:46 PM, Sandro Tosi wrote: >those are not many days to review the results of the conversions: can >you (or Stefano) share what were the problems that delayed the >transition, so that we can check in particular those aspects of the >packages we know the most? Stefano has put up sample migrations before, although by now they're pretty old. I don't remember the URL unfortunately. I think the delay is mostly just due to time constraints. If you're able to get an svn dump of the current DPMT svn repo, using the code at the URL I posted before, you can do a local migration. It doesn't take that long. Maybe Stefano can remind us of the URL when he reads this. Cheers, -Barry pgp5MdFmA6gE1.pgp Description: OpenPGP digital signature
Re: [DPMT] radical changes: automation, carrot and stick
On 10/02/2015 01:18 AM, Piotr Ożarowski wrote: > I think that the main problem of our team is that we have over 300 > members and only few people contribute to packages they didn't inject to > the repo (some people do not care even about those). Impressive that you write this after kicking me for daring to touch one of the packages in the team. Thomas
