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

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

Backport of python-lockfile and suggested team maintenance

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

Contents

  Backport of python-lockfile and suggested team maintenance Andreas Tille <andreas@an3as.eu> - 2017-03-02 11:00 +0100
    Re: Backport of python-lockfile and suggested team maintenance Ben Finney <bignose@debian.org> - 2017-03-03 12:00 +0100
      Re: Backport of python-lockfile and suggested team maintenance Andreas Tille <tille@debian.org> - 2017-03-06 15:50 +0100
        Re: Backport of python-lockfile and suggested team maintenance Ben Finney <bignose@debian.org> - 2017-03-07 17:20 +0100
          Re: Backport of python-lockfile and suggested team maintenance Andreas Tille <tille@debian.org> - 2017-03-08 17:00 +0100
            Re: Backport of python-lockfile and suggested team maintenance Ben Finney <bignose@debian.org> - 2017-03-09 13:50 +0100
              Re: Backport of python-lockfile and suggested team maintenance Andreas Tille <tille@debian.org> - 2017-03-10 13:30 +0100
                Re: Backport of python-lockfile and suggested team maintenance Ben Finney <bignose@debian.org> - 2017-03-11 01:50 +0100
    Re: Backport of python-lockfile and suggested team maintenance Thomas Goirand <zigo@debian.org> - 2017-03-03 14:10 +0100
      Re: Backport of python-lockfile and suggested team maintenance Barry Warsaw <barry@debian.org> - 2017-03-03 15:30 +0100

#9299 — Backport of python-lockfile and suggested team maintenance

Hi Ben,

I just uploaded python-lockfile 0.12.2-2~bpo8+1 to backports since I
need it to backport python-schema-salad.

I would have loved to commit the changes to some team Git repository but
you are using a repository outside git.debian.org.  I'd consider it
sensible if you would consider maintaining the package inside DPMT and
the corresponding repository which enables easier contributions to the
package.

Kind regards

      Andreas.

-- 
http://fam-tille.de

[toc] | [next] | [standalone]

#9302

Andreas Tille <andreas@an3as.eu> writes:

> I would have loved to commit the changes to some team Git repository
> but you are using a repository outside git.debian.org.

Fortunately, Git is a distributed VCS; we can share changes between
repositories with all information preserved.

If you also publish your repository, you can ‘git request-pull’ to the
package maintainer address and I can see about getting them in.

> I'd consider it sensible if you would consider maintaining the package
> inside DPMT and the corresponding repository which enables easier
> contributions to the package.

I'm glad that there are multiple sensible options: the maintainer can be
a named person, the maintainer can be a team. I consider either of those
sensible.

-- 
 \        “None can love freedom heartily, but good men; the rest love |
  `\                           not freedom, but license.” —John Milton |
_o__)                                                                  |
Ben Finney

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

#9336

Hi Ben,

On Fri, Mar 03, 2017 at 09:50:59PM +1100, Ben Finney wrote:
> 
> Fortunately, Git is a distributed VCS; we can share changes between
> repositories with all information preserved.
> 
> If you also publish your repository, you can ‘git request-pull’ to the
> package maintainer address and I can see about getting them in.

Thanks for teching me git features.  However, if maintainers decide from
deriving what several people consider good practice of team maintenance
and put extra work on me (like creating an extra public repository) I'm
not willing to do this.  You probably see some advantages in maintaining
packaging outside git.debian.org.  Its you descision whether it
outweights direct commits from other maintainers to this repository.
 
> > I'd consider it sensible if you would consider maintaining the package
> > inside DPMT and the corresponding repository which enables easier
> > contributions to the package.
> 
> I'm glad that there are multiple sensible options: the maintainer can be
> a named person, the maintainer can be a team. I consider either of those
> sensible.

There was a longish discussion on Debian Project[1] and my reading of it
was that named person maintenance is not the prefered way.

Kind regards

      Andreas.

[1] https://lists.debian.org/debian-project/2016/12/threads.html

-- 
http://fam-tille.de

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

#9346

Andreas Tille <tille@debian.org> writes:

> However, if maintainers decide from deriving what several people
> consider good practice of team maintenance and put extra work on me
> (like creating an extra public repository) I'm not willing to do this.

I'm sorry to say that I am not clear on what that sentence means; I got
lost around “decide from deriving”.

The distributed nature of Git – choosing how to share commits between
repositories – is a core feature, and allows collaboration without
requiring access to the same filesystem.

As a maintainer of the package, I remain open to pull requests.

> There was a longish discussion on Debian Project[1] and my reading of
> it was that named person maintenance is not the prefered way.

You have said that you “consider it sensible” to maintain a package
within DPMT, and I have no objection to that position.

The discussion thread you point to has many opinions, some of them in
support of nominating a team as package maintainer. I have no objection
to that position.

Are you now expressing the separate position that you consider it *not*
sensible to name an individual as package maintainer? On what basis? In
the discussion thread you point to, I don't see anything to support
that.

-- 
 \     “[H]ow deep can a truth be — indeed, how true can it be — if it |
  `\             is not built from facts?” —Kathryn Schulz, 2015-10-19 |
_o__)                                                                  |
Ben Finney

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

#9352

Hi Ben,

On Wed, Mar 08, 2017 at 03:13:09AM +1100, Ben Finney wrote:
> Andreas Tille <tille@debian.org> writes:
> 
> > However, if maintainers decide from deriving what several people
> > consider good practice of team maintenance and put extra work on me
> > (like creating an extra public repository) I'm not willing to do this.
> 
> I'm sorry to say that I am not clear on what that sentence means; I got
> lost around “decide from deriving”.

You decided to use github instead of git.debian.org.  IMHO that is not
following good practice for Debian team maintenance since it makes
contributions (admitedly slightly!) harder.

> The distributed nature of Git – choosing how to share commits between
> repositories – is a core feature, and allows collaboration without
> requiring access to the same filesystem.
> 
> As a maintainer of the package, I remain open to pull requests.

The pull request would force me to create my own clone on Github and I'm
not willing to do this extra work, sorry.  If you are interested you can
fetch changes from the backported upload (or in case others might NMUs)
and if this effort from your side outwights the advantages you see from
Github over git.debian.org that's fine for me.

> > There was a longish discussion on Debian Project[1] and my reading of
> > it was that named person maintenance is not the prefered way.
> 
> You have said that you “consider it sensible” to maintain a package
> within DPMT, and I have no objection to that position.

Fine.
 
> The discussion thread you point to has many opinions, some of them in
> support of nominating a team as package maintainer. I have no objection
> to that position.
> 
> Are you now expressing the separate position that you consider it *not*
> sensible to name an individual as package maintainer? On what basis? In
> the discussion thread you point to, I don't see anything to support
> that.

DPMT policy[1] section "Maintainer".

Kind regards

        Andreas.


[1] https://python-modules.alioth.debian.org/policy.html

-- 
http://fam-tille.de

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

#9360

My bafflement at the particulars of your complaint have not been
resolved, Andreas. I can only think you're confused about
‘python-lockfile’; much of your latest message just doesn't match the
facts.

Andreas Tille <tille@debian.org> writes:

> You decided to use github instead of git.debian.org.

Is your complaint that the Debian packaging for ‘python-lockfile’ is on
GitHub? This is the first time it's been raised in this thread.

If so, please look to the VCS-Git and VCS-Browser fields for the
package; that assertion isn't true.

> IMHO that is not following good practice for Debian team maintenance

As you have pointed out, the package is not currently team maintained,
so “good practice for Debian team maintenance” doesn't bear on the
issues you've expressed for this package.

This thread started with your polite request (thank you!) that the
package *should* become team maintained, and we don't even seem to have
got to addressing that yet :-)

> since [hosting at GitHub] makes contributions (admitedly slightly!)
> harder.

Agreed – I think the barriers are significant – which is one reason the
packaging is not hosted at GitHub.

> > As a maintainer of the package, I remain open to pull requests.
>
> The pull request would force me to create my own clone on Github

Since the Debian packaging work is not hosted at GitHub, no that would
not be necessary.

Even if it were hosted at GitHub, that assertion is not true: Git can
pull from *any* published repository.

I've already pointed out that two published repositories can share full
change information *without* being hosted at the same provider. Even one
hosted in a Debian developer's personal Alioth space works fine
<URL:https://wiki.debian.org/Alioth/Git#Personal_Git_repositories>.

So, I'm open to pull requests (whether created with ‘git request-pull’
or otherwise) from a published repository that I can point Git to.
Nothing about this requires anyone to host a repository at the same
provider.

> > Are you now expressing the separate position that you consider it
> > *not* sensible to name an individual as package maintainer? On what
> > basis?

I would still like an answer to this, because I must admit I am now
baffled as to what your complaint is and on what you base it.

Does it help address your complaint that I've hopefully cleared up some
incorrect assumptions? I hope so.

If you'd like to discuss on OFTC my nick is ‘bignose’.

-- 
 \     “If I held you any closer I would be on the other side of you.” |
  `\                                                     —Groucho Marx |
_o__)                                                                  |
Ben Finney

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

#9365

Hi Ben,

On Thu, Mar 09, 2017 at 11:41:44PM +1100, Ben Finney wrote:
> > You decided to use github instead of git.debian.org.
> 
> Is your complaint that the Debian packaging for ‘python-lockfile’ is on
> GitHub? This is the first time it's been raised in this thread.

May be I messed up with Github but I was rather addressing != git.d.o:

$ apt-cache showsrc python-lockfile | grep ^Vcs
Vcs-Browser: https://notabug.org/bignose/debian_python-lockfile/
Vcs-Git: https://notabug.org/bignose/debian_python-lockfile.git
 
> > The pull request would force me to create my own clone on Github
> 
> Since the Debian packaging work is not hosted at GitHub, no that would
> not be necessary.

I hope you will be able to excuse my false claim about Github.
 
> > > Are you now expressing the separate position that you consider it
> > > *not* sensible to name an individual as package maintainer? On what
> > > basis?
> 
> I would still like an answer to this, because I must admit I am now
> baffled as to what your complaint is and on what you base it.

In your last mail you agreed that team maintenance would acceptable
and I have pointed you to the DPMT policy which states that the
list should be set as maintainer.
 
> Does it help address your complaint that I've hopefully cleared up some
> incorrect assumptions? I hope so.
> 
> If you'd like to discuss on OFTC my nick is ‘bignose’.

I'm sorry, I have the feeling I have spent to much time into this
discussion even now.

Please just follow my suggestion to join DPMT or don't do it.

Thanks for considering

      Andreas.

-- 
http://fam-tille.de

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

#9366

Andreas Tille <tille@debian.org> writes:

> In your last mail you agreed that team maintenance would acceptable

To clarify: I've not agreed with that.

Rather, I've agreed with your position that the practice of a team as
maintainer is sensible, and I've said the practice of an individual as
maintainer is sensible.

A particular package can't be both of those at once, of course. But both
are common practice in Debian, and both are sensible.

So, a decision of which to choose can't be based only on “option X is
sensible”, because that doesn't argue *against* other options.

What I've been confused by is the conflation of “team as maintainer is
sensible”, which I agree with, and some implicit assumption of
“individual as maintainer is *not* sensible”, which I don't agree with.

I haven't got an answer from you on whether that's your position, so I
don't even know what argument you're presenting.

> Thanks for considering

I've tried :-) but haven't even seen any reason presented to change the
package maintenance from what it is now. I'd consider it if that were
presented.

As for the Git commits you've made for backports: I remain open to
considering a pull request from any published Git repo at your choice of
host.

-- 
 \       “The great thing about science is we can test our ideas.… But |
  `\   until we do, until we have data, it is just one more proposal.” |
_o__)                                     —Darren Saunders, 2015-12-02 |
Ben Finney

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

#9304

On 03/02/2017 10:52 AM, Andreas Tille wrote:
> Hi Ben,
> 
> I just uploaded python-lockfile 0.12.2-2~bpo8+1 to backports since I
> need it to backport python-schema-salad.
> 
> I would have loved to commit the changes to some team Git repository but
> you are using a repository outside git.debian.org.  I'd consider it
> sensible if you would consider maintaining the package inside DPMT and
> the corresponding repository which enables easier contributions to the
> package.
> 
> Kind regards
> 
>       Andreas.

Please consider that python-lockfile is considered deprecated upstream,
and only maintained for bugs and security. There's alternative
available, like python-oslo.concurrency.

Cheers,

Thomas Goirand (zigo)

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

#9305

On Mar 03, 2017, at 02:03 PM, Thomas Goirand wrote:

>Please consider that python-lockfile is considered deprecated upstream,
>and only maintained for bugs and security. There's alternative
>available, like python-oslo.concurrency.

ObPlug: Or flufl.lock, albeit with a different API and other (sometimes
interesting) semantics.

Cheers,
-Barry

[toc] | [prev] | [standalone]

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

csiph-web