Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #7401 > unrolled thread

[DPMT] radical changes: automation, carrot and stick

Back to article view | Back to linux.debian.maint.python

Contents

  [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 01:20 +0200
    Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 09:50 +0200
      Re: [DPMT] radical changes: automation, carrot and stick Vincent Bernat <bernat@debian.org> - 2015-10-02 10:20 +0200
        Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 10:40 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Vincent Bernat <bernat@debian.org> - 2015-10-02 11:00 +0200
            Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 11:20 +0200
          Re: [DPMT] radical changes: automation, carrot and stick IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-05 12:40 +0200
        Re: [DPMT] radical changes: automation, carrot and stick Elena ``of Valhalla'' <elena.valhalla@gmail.com> - 2015-10-02 11:00 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 11:30 +0200
            Re: [DPMT] radical changes: automation, carrot and stick Elena ``of Valhalla'' <elena.valhalla@gmail.com> - 2015-10-02 13:40 +0200
            Re: [DPMT] radical changes: automation, carrot and stick Barry Warsaw <barry@debian.org> - 2015-10-02 16:40 +0200
      Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-02 13:30 +0200
    Re: [DPMT] radical changes: automation, carrot and stick Nikolaus Rath <Nikolaus@rath.org> - 2015-10-02 18:20 +0200
      Re: [DPMT] radical changes: automation, carrot and stick Scott Kitterman <debian@kitterman.com> - 2015-10-02 20:30 +0200
      Re: [DPMT] radical changes: automation, carrot and stick IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-05 12:00 +0200
      Re: [DPMT] radical changes: automation, carrot and stick Arthur de Jong <adejong@debian.org> - 2015-10-07 14:10 +0200
        Re: [DPMT] radical changes: automation, carrot and stick Piotr Ożarowski <piotr@debian.org> - 2015-10-07 14:20 +0200
          Re: [DPMT] radical changes: automation, carrot and stick IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-07 14:40 +0200
          team vs individual as maintainer (was: radical changes) "W. Martin Borgert" <debacle@debian.org> - 2015-10-07 14:40 +0200
            Re: team vs individual as maintainer (was: radical changes) Barry Warsaw <barry@debian.org> - 2015-10-07 15:30 +0200
              Re: team vs individual as maintainer Piotr Ożarowski <piotr@debian.org> - 2015-10-07 15:40 +0200
                Re: team vs individual as maintainer "W. Martin Borgert" <debacle@debian.org> - 2015-10-07 15:50 +0200
                Re: team vs individual as maintainer Barry Warsaw <barry@debian.org> - 2015-10-07 15:50 +0200
                  Re: team vs individual as maintainer Piotr Ożarowski <piotr@debian.org> - 2015-10-07 16:10 +0200
                    Re: team vs individual as maintainer Barry Warsaw <barry@debian.org> - 2015-10-07 16:20 +0200
                Re: team vs individual as maintainer Piotr Ożarowski <piotr@debian.org> - 2015-10-17 00:00 +0200
                  git instead of svn in policy (was Re: team vs individual as  maintainer) IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-17 20:20 +0200
                    Re: git instead of svn in DPMT policy Piotr Ożarowski <piotr@debian.org> - 2015-10-17 20:50 +0200
                      Re: git instead of svn in DPMT policy Brian May <brian@microcomaustralia.com.au> - 2015-10-18 03:10 +0200
                      Re: git instead of svn in DPMT policy Sandro Tosi <morph@debian.org> - 2015-10-18 13:50 +0200
                      Re: git instead of svn in DPMT policy Barry Warsaw <barry@python.org> - 2015-10-19 18:10 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Arthur de Jong <adejong@debian.org> - 2015-10-07 15:40 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Nikolaus Rath <Nikolaus@rath.org> - 2015-10-07 17:10 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Raphael Hertzog <hertzog@debian.org> - 2015-10-07 18:30 +0200
    Re: [DPMT] radical changes: automation, carrot and stick Scott Kitterman <debian@kitterman.com> - 2015-10-02 20:40 +0200
      Re: [DPMT] radical changes: automation, carrot and stick Stefano Rivera <stefanor@debian.org> - 2015-10-05 00:00 +0200
        Re: [DPMT] radical changes: automation, carrot and stick Brian May <brian@microcomaustralia.com.au> - 2015-10-05 00:40 +0200
        Re: [DPMT] radical changes: automation, carrot and stick Scott Kitterman <debian@kitterman.com> - 2015-10-05 13:30 +0200
          Re: [DPMT] radical changes: automation, carrot and stick Barry Warsaw <barry@debian.org> - 2015-10-06 00:10 +0200
    Re: [DPMT] radical changes: automation, carrot and stick Thomas Goirand <zigo@debian.org> - 2015-10-03 01:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#7529 — Re: team vs individual as maintainer

[Barry Warsaw, 2015-10-07]
> * Team in Maintainers is a strong statement that fully collaborative
>   maintenance is preferred.  Anyone can commit to the vcs and upload as
>   needed.  A courtesy email to Uploaders can be nice but not required.
> 
> * Team in Uploaders is a weak statement of collaboration.  Help in maintaining
>   the package is appreciated, commits to vcs are freely welcomed, but before
>   uploading, please contact the Maintainer for the green light.

how about making it official and adding it to the policy?
-- 
evil Piotr

[toc] | [prev] | [next] | [standalone]

#7531 — Re: team vs individual as maintainer

Quoting Piotr Ożarowski <piotr@debian.org>:
> [Barry Warsaw, 2015-10-07]
>> * Team in Maintainers is a strong statement that fully collaborative
>>   maintenance is preferred.  Anyone can commit to the vcs and upload as
>>   needed.  A courtesy email to Uploaders can be nice but not required.
>>
>> * Team in Uploaders is a weak statement of collaboration.  Help in  
>> maintaining
>>   the package is appreciated, commits to vcs are freely welcomed, but before
>>   uploading, please contact the Maintainer for the green light.

+1

> how about making it official and adding it to the policy?

+1

[toc] | [prev] | [next] | [standalone]

#7532 — Re: team vs individual as maintainer

On Oct 07, 2015, at 03:29 PM, Piotr Ożarowski wrote:

>[Barry Warsaw, 2015-10-07]
>> * Team in Maintainers is a strong statement that fully collaborative
>>   maintenance is preferred.  Anyone can commit to the vcs and upload as
>>   needed.  A courtesy email to Uploaders can be nice but not required.
>> 
>> * Team in Uploaders is a weak statement of collaboration.  Help in maintaining
>>   the package is appreciated, commits to vcs are freely welcomed, but before
>>   uploading, please contact the Maintainer for the green light.
>
>how about making it official and adding it to the policy?

I thought you had volunteered to do that (with native speaker review)?  I
previously mistakenly remembered Scott volunteering for that.

If not, I'm happy to do it.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7534 — Re: team vs individual as maintainer

[Multipart message — attachments visible in raw view] — view raw

[Barry Warsaw, 2015-10-07]
> >how about making it official and adding it to the policy?
> 
> I thought you had volunteered to do that (with native speaker review)?  I
> previously mistakenly remembered Scott volunteering for that.
> 
> If not, I'm happy to do it.

I meant to use your exact words, see attachment
-- 
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

[toc] | [prev] | [next] | [standalone]

#7535 — Re: team vs individual as maintainer

On Oct 07, 2015, at 04:08 PM, Piotr Ożarowski wrote:

>I meant to use your exact words, see attachment

+1 !

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7678 — Re: team vs individual as maintainer

[Multipart message — attachments visible in raw view] — view raw

[Piotr Ożarowski, 2015-10-07]
> [Barry Warsaw, 2015-10-07]
> > * Team in Maintainers is a strong statement that fully collaborative
> >   maintenance is preferred.  Anyone can commit to the vcs and upload as
> >   needed.  A courtesy email to Uploaders can be nice but not required.
> > 
> > * Team in Uploaders is a weak statement of collaboration.  Help in maintaining
> >   the package is appreciated, commits to vcs are freely welcomed, but before
> >   uploading, please contact the Maintainer for the green light.
> 
> how about making it official and adding it to the policy?

done. I also added policy.rst file to python-modules.git repo (it still
clearly states we use SVN only, though!)
-- 
evil general Piotr

[toc] | [prev] | [next] | [standalone]

#7679 — git instead of svn in policy (was Re: team vs individual as maintainer)

[Multipart message — attachments visible in raw view] — view raw

On 10/16/2015 11:53 PM, Piotr Ożarowski wrote:
> (it still clearly states we use SVN only, though!)

since you have already mentioned this a few times: how about changing
the policy then, to clearly state that we use GIT only?

as you haven't done that yet, i guess there is some catch; but since i
only joined the team a few months ago i might have missed that.
(might be that the catch is simply one of priviliges to modify the policy)

mdsar
IOhannes

[toc] | [prev] | [next] | [standalone]

#7680 — Re: git instead of svn in DPMT policy

[Multipart message — attachments visible in raw view] — view raw

[IOhannes m zmölnig (Debian/GNU), 2015-10-17]
> since you have already mentioned this a few times: how about changing
> the policy then, to clearly state that we use GIT only?

yeah, how about changing it? So many people complain about SVN and
when it comes to do the actual work only one or two stepped up (the ones
that weren't complaining, BTW).

How about someone else, especially those who were so eager to move to git,
volunteer some time and prepare changes in policy?

> as you haven't done that yet, i guess there is some catch; but since i
> only joined the team a few months ago i might have missed that.
> (might be that the catch is simply one of priviliges to modify the policy)

the catch is it takes longer than writing an email

I moved policy.rst to python-modules.git repo (it was available to edit
by every team member in SVN as well). It's not OK to edit it and push it
without having a discussion here (on this mailing list) first, though.
-- 
evil general Piotr

[toc] | [prev] | [next] | [standalone]

#7682 — Re: git instead of svn in DPMT policy

Piotr Ożarowski <piotr@debian.org> writes:
> I moved policy.rst to python-modules.git repo (it was available to edit
> by every team member in SVN as well). It's not OK to edit it and push it
> without having a discussion here (on this mailing list) first, though.

Ok to push to a non-master branch? e.g. post-git-migrate?

As a first step, I would suggest deleting the entire "Subversion
Procedures" section. Maybe it could be replaced by a "Git Procedures"
section that has a link to the wiki page?

https://wiki.debian.org/Python/GitPackaging
-- 
Brian May <brian@microcomaustralia.com.au>

[toc] | [prev] | [next] | [standalone]

#7684 — Re: git instead of svn in DPMT policy

On Sat, Oct 17, 2015 at 7:49 PM, Piotr Ożarowski <piotr@debian.org> wrote:
> [IOhannes m zmölnig (Debian/GNU), 2015-10-17]
>> since you have already mentioned this a few times: how about changing
>> the policy then, to clearly state that we use GIT only?
>
> yeah, how about changing it? So many people complain about SVN and
> when it comes to do the actual work only one or two stepped up (the ones
> that weren't complaining, BTW).
>
> How about someone else, especially those who were so eager to move to git,
> volunteer some time and prepare changes in policy?

indeed! there is also http://python-modules.alioth.debian.org/ to update

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[toc] | [prev] | [next] | [standalone]

#7688 — Re: git instead of svn in DPMT policy

[Multipart message — attachments visible in raw view] — view raw

On Oct 17, 2015, at 08:49 PM, Piotr Ożarowski wrote:

>I moved policy.rst to python-modules.git repo (it was available to edit
>by every team member in SVN as well). It's not OK to edit it and push it
>without having a discussion here (on this mailing list) first, though.

I will make a pass through the file and push a non-master branch for review.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7528

[Multipart message — attachments visible in raw view] — view raw

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 package@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 - adejong@debian.org - http://people.debian.org/~adejong --

[toc] | [prev] | [next] | [standalone]

#7536

On Oct 07 2015, Piotr Ożarowski <piotr@debian.org> 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.«

[toc] | [prev] | [next] | [standalone]

#7537

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/

[toc] | [prev] | [next] | [standalone]

#7428

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#7450

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

[toc] | [prev] | [next] | [standalone]

#7451

[Multipart message — attachments visible in raw view] — view raw

On Mon, 5 Oct 2015 at 08:54 Stefano Rivera <stefanor@debian.org> 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.

[toc] | [prev] | [next] | [standalone]

#7457

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

[toc] | [prev] | [next] | [standalone]

#7482

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

[toc] | [prev] | [next] | [standalone]

#7431

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.maint.python

csiph-web