Re: [DPMT] radical changes: automation, carrot and stick
On Wed, 07 Oct 2015, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? While I understand the desire to have one identified maintainer for each package, I don't agree with the rule. Changing maintainer means changing the flow of information and it is a pain. When I get interested in a package, I subscribe to the package in the tracker. At some point, I end up the "maintainer" because the former maintainer left and here I should put myself in maintainer... that would mean getting duplicate mails and me having to fix my subscriptions or add procmail rules to avoid this. So I don't think that this rule gives us more benefits than annoyances. If you want to identify someone as in charge, let's define that the first person in the Uploaders field is that person. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: [DPMT] radical changes: automation, carrot and stick
On Oct 07 2015, Piotr Ożarowski wrote: > I no longer think requiring contribution (the 3 months thing) is a good > idea for DPMT (might be for a new team). > > I assume you all like other ideas, like no team in Maintainer, right? > > * 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 > * emails with all commits (diffs) made by someone not listed in Maintainer > are automatically sent to Maintainer Sounds good to me. > * 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... No opinion, I'd need a sponsor anyway. > * 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) > > [¹] as in upload to unstable without DPMT in Uploaders, repo stays in > case one decides come back Not sure about that one. What would be gained by this? What if the package is simply in good shape and doesn't need contributions? 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 Wed, 2015-10-07 at 14:18 +0200, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? I kind of liked the differentiation between the two options: - I'm the primary maintainer and welcome other people working on my packages (me in Maintainer, team in Uploaders) - I don't feel primarily responsible for the package but the package is useful (team in Maintainer, me in Uploaders) I think I only added packages in the first category but I also think I mostly contributed to other packages in the second category. For most of my packages I'm also upstream and I usually manage so I would appreciate a heads-up before someone else makes major changes to my packages. On the other hand, anything that would make it less work to help other packages would be positive. Avoiding spending time on trying to get feedback from people would be good. I think I'm OK with giving up some authority to my packages in exchange for lowering the total work required for maintaining all packages. In general it is probably a net positive for Debian to have less individual ownership of packages because it creates bottlenecks. I would welcome having more tools and policy around this. In that sense, switching to Git can probably help (thanks to everyone working on that). For example mailing pack...@packages.debian.org with a pull request would be great. By the way, still can't promise I'll be able to do much work on other packages in the near future ;) -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: [DPMT] radical changes: automation, carrot and stick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-10-07 14:18, Piotr Ożarowski wrote: > I no longer think requiring contribution (the 3 months thing) is a > good idea for DPMT (might be for a new team). > > I assume you all like other ideas, like no team in Maintainer, > right? if that's the new policy to be, i'm all happy with it. fgks IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWFRA4AAoJELZQGcR/ejb4dswP/1/xeEirq5bDspvNRKKZE935 UOu5PSQgpxMVRUJB04FwtwKfFA0eaHSHlIaHO/X7cZ2TVRTQZgxD2hMI4CiSVx04 VDtf7rp7L4DsQtxv8j6ujI60Tu2a3iatedbfSeKdUKOGwakjL8CGG+/QNxGWZzkL U7VnBOe3lQqDMd9mZoo/La9wguvkFzia72g/QtazORhRuKw5+6h6j2ZFUpac5278 35mbQYrnj4IlSUKinMXj3QNzuLWsVJR4RIpaYLp46DvknDBoW86fDKhfBcl7vFgT HkZYqAHxw3E1hiyTFBPfkQaUWetk8oBoURVjknH9c/pPMw8ig+ALLvbGjqHlr2a3 AGjSPAJ5/C1UDyyaP2jFtQKYQiUsrQp+xeX2zYvWJc6Z+hg/zKRs/qfFVgNaJS8b GR/qs4+aFKH2hifFfMga1PKMRgIOpo4kqo245ujnjk9A9Uze8/v46lZOOMTeZmED v0UInsg52B9/r0qJtle9o518qO+kSQR9ogM42yamG2RUleJhrM7UOjDCvL03JVBl POpfQGeo2DPJjhLhuDfKHTggjDUZuk18bBUmF539ggOf45zaCnW57DSQDbGAL1N+ Jpse9rxmECI6hR3Wb/zsbu9HrnlrJykagN1Eje5SsPck//lm4gUQKuFZPs+R0IqQ NHCtEkEmqaOA/AC5FL3i =d+wY -END PGP SIGNATURE-
Re: [DPMT] radical changes: automation, carrot and stick
I no longer think requiring contribution (the 3 months thing) is a good idea for DPMT (might be for a new team). I assume you all like other ideas, like no team in Maintainer, right? -- evil Piotr
Re: [DPMT] radical changes: automation, carrot and stick
On Fri, 2015-10-02 at 09:12 -0700, Nikolaus Rath wrote: > 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. Same here. I have a few packages in DPMT and PAPT because I think it improves the overall quality of Debian packages if they are centrally maintained. Having centralised infrastructure and policy makes it much easier to fix things across many packages (e.g. helper package migrations or updating the (XS-)Vcs-* fields). I can't say I contribute regularly to other package in either of the repositories but once in a while I do have time to do QA-like work on a few packages that are team maintained. In short, I don't see why I am considered a problem for the team. I'm not saying I'm a hugely positive addition but removing my packages because I don't contribute much to other packages will not motivate me to do more and will probably have the opposite effect for when I do have some time to spare. Thanks, -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: [DPMT] radical changes: automation, carrot and stick
On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote: >There's a fundamental question to ask here. Do we want to welcome Python >packages into the team, or do we want to put up barriers and require a >level of commitment before packages can be brought into the team? Thanks Stefano for stating this in such a clear way. It is indeed a (*the*?) fundamental question to ask about this team. On Oct 05, 2015, at 07:23 AM, Scott Kitterman wrote: >I think that you describe to reasonably accurate directions the team can go. >Personally, I prefer the "natural home for most Python packages in the >archive" vision. > >I think we should have a minimum of rules, but people should follow the ones >we do have. +1 and +1 Cheers, -Barry
Re: [DPMT] radical changes: automation, carrot and stick
On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote: > This thread has had me thinking a bit. > > Hi Scott (2015.10.02_20:34:16_+0200) > > > 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. > > I like it too, but I don't actually use it very accurately. Whether I'm > maintainer or uploader for a package is more an accident of history than > anything else. I should probably fix that. > > That said I haven't found it makes much difference to people's > contributions to my packages. I've woken up to find that something was > added to SVN and uploaded, immediately. > > > Personally, I would find this kind of rule demotivating. I think it will > > actually discourage participation which isn't what we want. > > There's a fundamental question to ask here. Do we want to welcome Python > packages into the team, or do we want to put up barriers and require a > level of commitment before packages can be brought into the team? > > What are the possible outcomes of either choice? > > > I'd imagine that if we're open, we become the natural home for most > Python packages in the archive. > Transitions become easier, and standardisation of the vast majority of > Python packages in the archive is within our power. > > We'll collect cruft. But so does the rest of the archive. I don't think > being open will necessarily increase the amount of crufty Python in the > archive. > > > On the other hand, if we raise barriers, we reduce the size and > influence of the team. The few packages we maintain, we can probably > maintain to a higher standard. Maybe there'd be less bickering, because > we'd be working together more (not that I think we have much). > Newcomers would be rarer (there's a commitment) but more valuable to the > team. Or would we start to attract people faster because of our level of > activity? > > Of the newcomers we turn away, I don't think most will abandon their pet > packages. They'll just not do it in our team. New Python teams will form, > and many more Python packages will be individually maintained. I know > most of us have QA interests wider than the team, and this isn't > desirable for us. > > How would we feel if a cabal-free-python team formed? Would any of us > join it? > > And as to cruft. What happens when a widely-used package that is > maintained by a 3-month inactive maintainer gets evicted? Do we orphan > it? Alternatively, is the team prepared to take on all these packages? > > > If we want to seriously think about these issues, should we start > lighter-weight? > > * Audit the team for crufty packages that should be RMed. > * or need love. > * Audit the team for inactive members. > * ... and their packages. > > Doing something about these is within our power right now. > > Can we find "carrot" ways to encourage team members to work on packages > besides their own? > > Many of the problems arising from inactive team members are problems > that affect the wider Debian, equally. I think that you describe to reasonably accurate directions the team can go. Personally, I prefer the "natural home for most Python packages in the archive" vision. I think we should have a minimum of rules, but people should follow the ones we do have. Scott K
Re: [DPMT] radical changes: automation, carrot and stick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-10-02 10:30, Piotr Ożarowski wrote: > it's 3 months to contribute to other packages (the ones where > you're not listed in Maintainer). hmm. if i - hypthotically, because i really currently do not - cared a so much about e.g. 30 DPMT packages¹ that i have added myself to the Uploaders and which have active upstreams and thus require a fair amount of regular maintainance work, then i would need to do to *another* contribution each month in order to not get kicked out of the team? sounds a bit like penalizing the wrong ones to me. fgamsdr IOhannes ¹ just made up numbers; assuming only a single real person is in "Uploaders/Maintainers"; and that the 16 team members listed in https://wiki.debian.org/Teams/PythonModulesTeam are the only really active ones; and that all other 300 members only injected a single package into the current 779 ones; gives the active members about 30 packages each on average. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWElJMAAoJELZQGcR/ejb4vwsP/0xbLTgajbmg7AyJzeStWulR 5ggQQx1L853ER69sqR9Kfmv9+cBo2ijl39m+libY8o20QUyglM4+/QKNYA2mto5X izcPA+ZD0RFePA5z9yCHZNBUQnLpNX9C8+N0qAWAdeVO7fYUbkr3plBvaP+CvdLc Fv8OQ0t5dNYnmnMV3T6BYmCxqJMido0FM78n8xhE+A1XSs+saBjA3JlXyyNxy7MC V3K0/SYtV0db4rhboTrrGRaDv6ZQMIlL+czEWfDgwBqnWVtK3AdZSLZdJRF9JeN8 CWjv4CjEADeI2vtt38dYvj8GVlm5G6b528bP/ABrbCVPm4DO18zjpnIxILFPnGcg 0C07nWtcnceRW2mcR/tFERTTtWfa8l77cpf4VknKb9dCKfiHn9buB1YLFfWKi9wm l8ZvyTg74apMpX583bdOvlAkzVp+nGv7TYUxxdntKj2/H/Phwz1cbb68vQ5onhNP B7JZMlJPao3PrEqKnv6ftBR8AO1/WD6aEeJRlBBHQjONCSeQZuERMv8CWWSoUt2J Zy0Ak4TuGvzsuik6nQhszVV48G/h9vlWJPeHhfddJPrQPLhA+u9zKqLumB2QipoD 5lb5BcPEUzszvi3Lw56vSTkMTqJ88GE+zC2GeILFP5aS+uRJ9Yihcd0D1ZzXoLoV MjEfLMt/EDZmmzQTO22p =6kim -END PGP SIGNATURE-
Re: [DPMT] radical changes: automation, carrot and stick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-10-02 18:12, 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? this was also my impression and the main reason why i joined the team. i brought in 3 packages needed as a dependency for some other package maintained by pkg-multimedia; the 3 modules are general purpose, so it makes little sense to maintain them in pkg-multimedia - DPMT seemed to be the right place. as others have mentioned, i also set DPMT as "maintainer", in order to not keep anybody from contributing (and not because I wanted to unload the packaging burden on the team). fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWEkhCAAoJELZQGcR/ejb41YgP/3n5Ji/EUuzUhHI3+MRHMa6I etTAP3KJkKtKipKOdgnmUDn4XLLM+aM4M3V2Y1O/FOu+R/dJc/+ynnGZS47twLJm edjFNSRhjiLDGTk4Io0m7jgV80YCr+5MfCe2/dnrIE4mEM4z69Cjo6cR+G2adz8f EhoScamtuhkyJ26fH3OMgBTWJLMwP1zUilhySSCxvRf8U7mSBHH2ugNdu7ph7t1N EL4e2ySvV0JNA2Pd6PQG/6vL8/EvMpzLXBBeLAAAm63kT2UhLryb5yTABFIxyz3d odn+hVFHhJuoTRxYiH6apTr/RxX1za7lYAY7aXcsIt1h/jL3uy6L4vm3XtJReAaR 6FWqVjoJdHzn/NUID3bgHTv4L2csolKI+TPcnvpzR0VYMOtcNfIVhkKEthTP0ybC D7iPKtqtK/idM34Oc7cZnF0Abk4LWr9kakgt816mNsm4/GI9e1ipqwyQNx/21eF0 cBVfjX1+xQohRP+7Lw58+RTVHPUp05Z5ld8qD0XrNwMWjF3HiASo65HVUVVy0cph lYwPgG8mk46a+Bsxy4Kjvi4LAY33MeUphbsGfgqMA11eUF9zHtbPIBetxh1+Ip46 geU06DiPsX4CE70WLnAZoQQujANG/haSI1/ULF19pouC7L7sLN711PuQ4WvEh5M6 foeUUpjt2NzuFvR2KCbF =n8eR -END PGP SIGNATURE-
Re: [DPMT] radical changes: automation, carrot and stick
On Mon, 5 Oct 2015 at 08:54 Stefano Rivera wrote: > There's a fundamental question to ask here. Do we want to welcome Python > packages into the team, or do we want to put up barriers and require a > level of commitment before packages can be brought into the team? Speaking for myself, I welcome anybody working on 'my' packages. As in making changes to subversion/git or even uploading packages. Sure mistakes can happen, packages might even become broken, however I think the risks of packages going unmaintained is far more damaging. I had several packages or mine fail to get into Jessie, because of trivial release critical bugs in dependent packages, and the official maintainer ignored the bug reports. I believe this is why we have team maintainers - so anybody can work on the packages. Yes - I could have also done an immediate NMU - however not being the maintainer I wasn't aware of the release critical bug until the packages had been removed and it was too late to do anything - the release team wouldn't let one package back in despite the fact the only bug was a problem with the copyright file. My impression is that it is a minority that get upset when people upload 'their' packages to the Debian archive without asking for permission first. I think these people tend to be active developers, so maybe these maintainers should be treated as special cases? My understanding - correct me if I am wrong - is that nobody has ever complained about committing changes to subversion/git. Which rather puzzles me that Thomas Goirand was removed from DPMT and PAPT - I believe (am I mistaken?) this removes his ability to commit changes to subversion (which was OK), but not remove his ability to upload packages (which was not always OK). > On the other hand, if we raise barriers, we reduce the size and > influence of the team. The few packages we maintain, we can probably > maintain to a higher standard. Maybe there'd be less bickering, because > we'd be working together more (not that I think we have much). > Newcomers would be rarer (there's a commitment) but more valuable to the > team. Or would we start to attract people faster because of our level of > activity? > With fewer packages in the team, we would end up with more packages being out-of-date and poorly maintained. This would lead to even more people installing packages directly using pip, and Debian packaging would become less relevant for Python developers.
Re: [DPMT] radical changes: automation, carrot and stick
This thread has had me thinking a bit. Hi Scott (2015.10.02_20:34:16_+0200) > 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. I like it too, but I don't actually use it very accurately. Whether I'm maintainer or uploader for a package is more an accident of history than anything else. I should probably fix that. That said I haven't found it makes much difference to people's contributions to my packages. I've woken up to find that something was added to SVN and uploaded, immediately. > Personally, I would find this kind of rule demotivating. I think it will > actually discourage participation which isn't what we want. There's a fundamental question to ask here. Do we want to welcome Python packages into the team, or do we want to put up barriers and require a level of commitment before packages can be brought into the team? What are the possible outcomes of either choice? I'd imagine that if we're open, we become the natural home for most Python packages in the archive. Transitions become easier, and standardisation of the vast majority of Python packages in the archive is within our power. We'll collect cruft. But so does the rest of the archive. I don't think being open will necessarily increase the amount of crufty Python in the archive. On the other hand, if we raise barriers, we reduce the size and influence of the team. The few packages we maintain, we can probably maintain to a higher standard. Maybe there'd be less bickering, because we'd be working together more (not that I think we have much). Newcomers would be rarer (there's a commitment) but more valuable to the team. Or would we start to attract people faster because of our level of activity? Of the newcomers we turn away, I don't think most will abandon their pet packages. They'll just not do it in our team. New Python teams will form, and many more Python packages will be individually maintained. I know most of us have QA interests wider than the team, and this isn't desirable for us. How would we feel if a cabal-free-python team formed? Would any of us join it? And as to cruft. What happens when a widely-used package that is maintained by a 3-month inactive maintainer gets evicted? Do we orphan it? Alternatively, is the team prepared to take on all these packages? If we want to seriously think about these issues, should we start lighter-weight? * Audit the team for crufty packages that should be RMed. * or need love. * Audit the team for inactive members. * ... and their packages. Doing something about these is within our power right now. Can we find "carrot" ways to encourage team members to work on packages besides their own? Many of the problems arising from inactive team members are problems that affect the wider Debian, equally. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
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
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: [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 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 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: [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: [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: [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
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
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
❦ 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
[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 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
[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
