How does team maintenace of python module works?

[Thomas Goirand]

Hi,

Because I'm currently packaging Openstack Grizzly, which will be out
next April, I need a newer version of python-mock. So I filled:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699147

but no reply so far, and this worries me.

I haven't done the bug fillings for other python modules which I'm
concerned about, but the problem will be the same for others.

So I wonder, how is the python module packaging policy? Since this
module is marked as team maintained, and that I've been accepted in the
python module packaging team on Alioth, am I allowed to just refresh the
package, and upload version 1.0 in debian experimental? Or do I need
approval from current uploaders?

What does it mean for a package to be team maintained in the python
packaging team?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/511A58FA...@debian.org

[Dmitry Shachnev]

Hi Thomas,

On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand <zi...@debian.org> wrote:
> ...

> So I wonder, how is the python module packaging policy? Since this
> module is marked as team maintained, and that I've been accepted in the
> python module packaging team on Alioth, am I allowed to just refresh the
> package, and upload version 1.0 in debian experimental? Or do I need
> approval from current uploaders?
>
> What does it mean for a package to be team maintained in the python
> packaging team?

If the team is in Maintainer field, I think you can freely upload the
new version. See
<http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
for details.

The same should apply to PAPT as well.

--
Dmitry Shachnev

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAKimPHVb1xMOzwmteb_+AAUZ...@mail.gmail.com

[Dmitrijs Ledkovs]

On 12 February 2013 15:08, Dmitry Shachnev <mit...@gmail.com> wrote:
> Hi Thomas,
>
> On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand <zi...@debian.org> wrote:
>> ...
>> So I wonder, how is the python module packaging policy? Since this
>> module is marked as team maintained, and that I've been accepted in the
>> python module packaging team on Alioth, am I allowed to just refresh the
>> package, and upload version 1.0 in debian experimental? Or do I need
>> approval from current uploaders?
>>
>> What does it mean for a package to be team maintained in the python
>> packaging team?
>
> If the team is in Maintainer field, I think you can freely upload the
> new version. See
> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
> for details.

But please join the team and update the svn repository, or
alternatively ask somebody from the team to commit your upload.

Regards,

Dmitrijs.

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CANBHLUj8e2LVJzSYcERve7+t33cANU+2w=Q1Cref0z...@mail.gmail.com

[Thomas Goirand]

On 02/12/2013 11:13 PM, Dmitrijs Ledkovs wrote:
> On 12 February 2013 15:08, Dmitry Shachnev <mit...@gmail.com> wrote:
>> Hi Thomas,
>>
>> On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand <zi...@debian.org> wrote:
>>> ...
>>> So I wonder, how is the python module packaging policy? Since this
>>> module is marked as team maintained, and that I've been accepted in the
>>> python module packaging team on Alioth, am I allowed to just refresh the
>>> package, and upload version 1.0 in debian experimental? Or do I need
>>> approval from current uploaders?
>>>
>>> What does it mean for a package to be team maintained in the python
>>> packaging team?
>>
>> If the team is in Maintainer field, I think you can freely upload the
>> new version. See
>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>> for details.
>
> But please join the team and update the svn repository, or
> alternatively ask somebody from the team to commit your upload.
>
> Regards,
>
> Dmitrijs.

Hi,

Thanks for both of your replies.

I've joined the team on Alioth already.

The only problem is that I quite hate SVN (mostly because I never learn
it). Don't you guys have plans to switch to git at some point? I've seed
that in /git/python-modules/packages there's already 3 packages. Is it
fine to switch to Git?

There's a bunch of python modules which I maintain for Openstack. I'd
happily move them in the /git/python-modules/packages repository. :)

Cheers,

Thomas

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511A6A84...@debian.org

[Jakub Wilk]

* Thomas Goirand <zi...@debian.org>, 2013-02-13, 00:15:

>The only problem is that I quite hate SVN (mostly because I never learn
>it). Don't you guys have plans to switch to git at some point? I've
>seed that in /git/python-modules/packages there's already 3 packages.
>Is it fine to switch to Git?

http://lists.alioth.debian.org/pipermail/python-modules-team/2013-January/014959.html

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013021216...@jwilk.net

[Alberto Garcia]

On Wed, Feb 13, 2013 at 12:15:00AM +0800, Thomas Goirand wrote:

> The only problem is that I quite hate SVN (mostly because I never
> learn it).

Just can use git-svn just fine:

'git svn clone' instead of 'git clone'
'git svn rebase' instead of 'git pull'
'git svn dcommit' instead of 'git push'

and the rest is the normal git workflow.

Berto

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013021216...@igalia.com

[Sandro Tosi]

>> If the team is in Maintainer field, I think you can freely upload the
>> new version. See
>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>> for details.

Bug fixing is always fine for team-maintained pkgs, but just throwing
a new upstream release into the repository and they disappear is *not*
what team maintenance is for (which might be the situation at hand
given zigo just joined and we don't have any history); so please at
least try to get in contact with the uploaders first (isn't it xnox?)

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

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAB4XWXyMTF9k43XK=0_rM45FY26i9Obod...@mail.gmail.com

[Thomas Goirand]

On 02/14/2013 04:53 PM, Sandro Tosi wrote:
>>> If the team is in Maintainer field, I think you can freely upload the
>>> new version. See
>>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>>> for details.
>
> Bug fixing is always fine for team-maintained pkgs, but just throwing
> a new upstream release into the repository and they disappear is *not*
> what team maintenance is for

What makes you think that this is the kind of behavior that I will
adopt? Please don't without giving me the opportunity to do maintenance
work. Also, the fact that I'm introducing myself and asking what the
team rules is a good sign that I really do intend to do team work, and
integrate with whatever your work-flow is.

> (which might be the situation at hand
> given zigo just joined and we don't have any history); so please at
> least try to get in contact with the uploaders first (isn't it xnox?)

I did and received no reply. See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699147

which is what made me ask in this list, as I really need the module to
be updated (it's a build-dependency of other things I maintain).

Now, I will continue to use SVN for the modules maintained inside the
team, but I don't think I will put my currently maintained python
modules in SVN, as I prefer Git.

IMO, it's not very nice that you don't at least give the choice, and
impose an inferior VCS, especially considering that most (in fact,
currently *absolutely all*) upstream authors of the python modules I
maintain are using Git (and github), which makes it quit convenient to
use Git.

Is there a valid reason despite history? Is there a chance that this
rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be
the only one happy with such decision.

Cheers, and thanks for the many replies,

Thomas Goirand (zigo)

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511CD4A7...@debian.org

[Thomas Kluyver]

On 14 February 2013 12:12, Thomas Goirand <zi...@debian.org> wrote:

Is there a valid reason despite history? Is there a chance that this
rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be
the only one happy with such decision.

I don't know the history, but I'll voice my support for allowing team-maintained modules to live in git.

Please don't be put off by the somewhat hostile atmosphere that seems to be an unfortunate feature of this list. There seem to be historical tensions between some of the senior members.

Thomas

[Sandro Tosi]

On Thu, Feb 14, 2013 at 1:12 PM, Thomas Goirand <zi...@debian.org> wrote:
> On 02/14/2013 04:53 PM, Sandro Tosi wrote:
>>>> If the team is in Maintainer field, I think you can freely upload the
>>>> new version. See
>>>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>>>> for details.
>>
>> Bug fixing is always fine for team-maintained pkgs, but just throwing
>> a new upstream release into the repository and they disappear is *not*
>> what team maintenance is for

It's a warning

> What makes you think that this is the kind of behavior that I will
> adopt? Please don't without giving me the opportunity to do maintenance
> work. Also, the fact that I'm introducing myself and asking what the
> team rules is a good sign that I really do intend to do team work, and
> integrate with whatever your work-flow is.

I hadn't implied that you will, but since you haven't done any work
for the team yet (the history thing?), it's good to explain the
expectations before.

>> (which might be the situation at hand
>> given zigo just joined and we don't have any history); so please at
>> least try to get in contact with the uploaders first (isn't it xnox?)
>
> I did and received no reply. See:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699147

you can ask again at least.

> which is what made me ask in this list, as I really need the module to
> be updated (it's a build-dependency of other things I maintain).
>
> Now, I will continue to use SVN for the modules maintained inside the
> team, but I don't think I will put my currently maintained python
> modules in SVN, as I prefer Git.

sure, just don't put them under DPMT maintainership then.

> IMO, it's not very nice that you don't at least give the choice, and
> impose an inferior VCS, especially considering that most (in fact,
> currently *absolutely all*) upstream authors of the python modules I
> maintain are using Git (and github), which makes it quit convenient to
> use Git.
>
> Is there a valid reason despite history? Is there a chance that this
> rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be
> the only one happy with such decision.

please stop the discussion now, and accept what the team is currently using.

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

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAB4XWXz+Y=HsoBkv5Me5ALrgJS9X1D...@mail.gmail.com

[Thomas Goirand]

On 02/14/2013 08:52 PM, Thomas Kluyver wrote:
> Please don't be put off by the somewhat hostile atmosphere that seems to
> be an unfortunate feature of this list. There seem to be historical
> tensions between some of the senior members.
>
> Thomas

It is indeed not a very welcoming start at all.

Was there some tensions because some of the team members wished to
switch to Git, and there was some resistance against it? What do I miss?

(sorry, I have no time to read all the list archive...)

On 02/14/2013 08:50 PM, Sandro Tosi wrote:
>> IMO, it's not very nice that you don't at least give the choice, and
>> impose an inferior VCS, especially considering that most (in fact,
>> currently *absolutely all*) upstream authors of the python modules I
>> maintain are using Git (and github), which makes it quit convenient
>> to use Git.
>>

>> Is there a valid reason despite history? Is there a chance that this
>> rule may be reconsidered? It'd be really nice, as I'm sure I
>> wouldn't be the only one happy with such decision.
>

> please stop the discussion now, and accept what the team is currently
> using.

Sandro, I have some problems with such an answer, especially when I
tried to remain polite. This is an incentive so that I change my tone as
well, and that's not what I would expect from Debian packaging teams.

You can't just throw away my (IMO valid) arguments and say "it's like
that, don't complain or go away, plus I wont bother explaining why".
Because that's basically what you just wrote. Using another wording,
maybe, but that's exactly the same meaning.

Also, if you're fine to use SVN, it's your right, and I do respect it
(even if I think it's going 10 years backward). I will also try as much
as I can to use SVN for existing packages within the team, I think
that's the least I can do.

But nobody can force me into using SVN for the packages which I want to
maintain (and for the reasons I already explained). If there is a bunch
of people who wishes to collectively maintain a bunch of python module
packages using Git, there's nothing you can do to prevent it. If this
can't be done inside the python module team, because of some hostile
members, I think it's a shame. And indeed, I'll go away and package
these using another repository, outside of the team...

During these exchanges, I have already found that there's at least 4
people (including myself) who would like to use Git. And that's without
including all the members of the Openstack packaging team, who might
also help. Do you think that we should form another Alioth project for
that? Wouldn't that be silly? What are the alternatives that you see, if
we are a lot of people willing to do python module team maintenance
using Git?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511CFE0B...@debian.org

[Sandro Tosi]

On Thu, Feb 14, 2013 at 4:08 PM, Thomas Goirand <zi...@debian.org> wrote:
> Sandro, I have some problems with such an answer, especially when I
> tried to remain polite. This is an incentive so that I change my tone as
> well, and that's not what I would expect from Debian packaging teams.

so please search into the mailing list archive about the several
iterations of such discussion and the outcome of them.

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

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAB4XWXz1LVMdQSTgHFFS8-3Y...@mail.gmail.com

[Thomas Kluyver]

On 14 February 2013 16:41, Sandro Tosi <sandr...@gmail.com> wrote:

so please search into the mailing list archive about the several
iterations of such discussion and the outcome of them.

The most recent discussion I found with a quick search started nearly 2 years ago. Nobody appeared to be arguing strongly against the switch, although there were a few caveats, like having a sane migration path:

http://thread.gmane.org/gmane.linux.debian.devel.python/6540/

It looks more like the idea stalled than was rejected. If that is the case, it shouldn't be a problem to discuss it again.

Thomas

[Thomas Goirand]

On 02/15/2013 12:41 AM, Sandro Tosi wrote:
> On Thu, Feb 14, 2013 at 4:08 PM, Thomas Goirand <zi...@debian.org> wrote:
>> Sandro, I have some problems with such an answer, especially when I
>> tried to remain polite. This is an incentive so that I change my tone as
>> well, and that's not what I would expect from Debian packaging teams.
>
> so please search into the mailing list archive about the several
> iterations of such discussion and the outcome of them.

After some search, I have found some discussions about *switching* to
Git for *all* of the python module team, which is absolutely *not* what
I'm asking for. There's several of such tread indeed, from 2008, 2011,
and probably more, showing that there's a real interest into switching.
In fact, I mostly saw a lot more people willing to use Git and to switch
than I expected.

But..., no outcome at all. As it happens very often in Debian, there's
discussion but nothing happens, or not clear cut decision is made. If I
missed it, please point to me to the outcome email(s) so that I could
read it/them.

Anyway, yet, I have seen *NO* discussion about maintaining *some* of the
python modules using Git. Probably only this one:

https://lists.debian.org/debian-python/2011/03/msg00076.html

All this is very far from being *forbidden* to send packages to the
python module team using Git and maintain them this way.

If I missed some posts, please point to the relevant URL(s)!

Thomas

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511D1DF7...@debian.org

[Dmitry Shachnev]

I'm not against switching to Git, but one of the arguments last time
was that maintaining packages in different places will make
mass-commits like [1] more difficult.

[1]: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=18483

--
Dmitry Shachnev

Archive: http://lists.debian.org/CAKimPHWpArOJ++k1Ak==bZBV0YoFUMngq3DoJ6t8=aa1B...@mail.gmail.com

[Thomas Goirand]

On 02/15/2013 02:04 AM, Dmitry Shachnev wrote:
> I'm not against switching to Git

Hi Dmitry,

I believe there's some misunderstanding, so I must make it square.
Again, I'm *not* asking for a full switch (or any switch at all) of all
(or even some) packages of the python module team. I have *NEVER*
written such thing, so could anyone writing in this tread refrain from
switching to this topic? If you do want to talk about it (which would be
a great move, IMO), do it in another thread, or at least not as a reply
to my message.

What's happening is that some of the python modules which I maintain in
Git can continue to be maintained this way. Nothing more, nothing less.
I'm perfectly fine using git-svn for what exists already under the team
maintenance. However these:

python-cinderclient
python-cloudfiles
python-django-appconf
python-django-compressor
python-django-openstack-auth
python-extras
python-glanceclient
python-json-patch
python-json-pointer
python-jsonschema
python-keystoneclient
python-novaclient
python-pecan
python-quantumclient
python-swiftclient
python-tablib
python-warlock

which I have to maintain because they are dependencies of Openstack, I
am using some git commands in debian/rules to:
- generate the orig.tar.xz out of the git tree using "git archive"
- generate the MANIFEST.in using "git ls-files" (not on all pkgs though)
- generate the upstream changelog using "git log" (not on all pkgs though)

Also, upstream is using git, so being able to cherry-pick -x some
commits is quite convenient. Absolutely *all* of upstream packages are
hosted or mirrored on Github.

My build process of "openstack-pkg-builder" (scripts hosted on Alioth to
make sure that Openstack is easily "bootstrapable") is using git to
clone the packaging branch from Alioth, and the upstream branch from Github.

We also have some Jenkins jobs doing some basic checks (for the moment,
building in a cowbuilder, soon, piuparts too), also using Git.

Switching to SVN would be a brainless time consuming move, which I do
not intend to even debate. If it's mandatory to use SVN, I wont maintain
them inside the python module team, full stop.

So my request was: would the python module team accept *these packages*
to be maintained in Git? (probably, the python-*client will stay in the
Openstack Git repository on Alioth though)

Thomas


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511D32D9...@debian.org

[Barry Warsaw]

On Feb 15, 2013, at 01:25 AM, Thomas Goirand wrote:

>All this is very far from being *forbidden* to send packages to the
>python module team using Git and maintain them this way.

Of the three main dvcs's, I personally dislike git the most, but I'm resigned
to the fact that it's essentially won the dvcs wars. I would accept using it
officially for the team packages because it would make disconnected use
possible, and depending on the organization of packages and branches, could
introduce a much nicer workflow for updating packages, e.g. pull requests,
reviews, cherry picking, etc.

Having said that, I'm strongly against having team packages live in multiple
different vcses. Choice is good, and everyone has the choice to use whatever
vcs and hosting they want for their own packages, outside of the team. But
there is value in team consistency and I'd be loathe to give that up.

When working with any team, and especially of volunteers, you simply will not
get everything you want. Compromise is the only workable solution, especially
when there is no BDFL. I think it's important to accept team decisions and
not waste valuable time arguing about them. Trust me, I've lost my fair share
of arguments in upstream Python - it stings, but life is short :).

That's not to say such discussions can never happen, and in a loose
organization such as this team's it may be difficult to divine what consensus
actually is. I look at the switch to dh_python2 as an example. Not everyone
here agreed with that decision, many still do not. But Piotr and others put
in a considerable amount of hard work to make it a very viable, high quality
option. Rough consensus and working code means that I think you'd find a
majority of team members actively using it, happy with it, pleased at its
advantages over the other options, and experienced enough with it to recommend
it to others.

Switching to git or any other dvcs isn't going to happen just by asking for
it. Someone would have to step up and actually do a lot of hard work to make
it happen. Look at all the work done by upstream Python to get it onto
Mercurial. It was *a lot* of work, making sure the conversions were high
fidelity, that documentation was good, that the workflow made sense for the
use cases, that newbies to distributed vcs were guided through the concepts
and common practices, etc. etc. The folks who cared deeply about Mercurial
made a long term commitment to ensuring a smooth transition. That was an
argument that I lost, but I have to hand it to the winning side - minor rough
edges and initial problems aside, it's a system that is working very well for
the community today.

So if some percentage of team members really really want to switch to git,
step up and do enough of the work on spec (i.e. no guarantees) so that you
have something that is convincing. It doesn't have to have all the rough
edges polished off, but I do think it needs to very clearly demonstrate enough
of a win over svn for the team (or a majority of them) that it would be a good
switch. Please also do be respectful of the concerns of the detractors and
opponents, and try to address them as best you can.

Again, I say this as someone who doesn't mind svn and would accept git, but
feels very strongly that there should be one team vcs and repo.

Cheers,
-Barry

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130214152...@anarchist.wooz.org

[Thomas Kluyver]

On 14 February 2013 20:29, Barry Warsaw <ba...@python.org> wrote:

I look at the switch to dh_python2 as an example.

I don't think it's a particularly good example, though. Lots of packages continue to use the older helpers, and not due to a lack of time - attempts to move away from the deprecated helpers still seem to meet considerable resistance. That causes problems when newcomers don't want to learn deprecated packaging methods, and aren't allowed to update packages to use the recommended helper.

Back on the VCS question, I fear that the 'all or nothing' road will circle back to 'nothing' for a long time. I think that we should allow some packages to live in git without forcing a complete migration, so individual maintainers can use the VCS they're more comfortable with. Most open source programmers have at least a basic familiarity with both, so it shouldn't be such an obstacle to working on other packages.

We wouldn't be the only team doing this - Debian Games Team, for example, use both git and svn for packaging:
http://wiki.debian.org/Games/VCS

Thomas

[Barry Warsaw]

On Feb 14, 2013, at 08:54 PM, Thomas Kluyver wrote:

>I don't think it's a particularly good example, though. Lots of packages
>continue to use the older helpers, and not due to a lack of time - attempts
>to move away from the deprecated helpers still seem to meet considerable
>resistance. That causes problems when newcomers don't want to learn
>deprecated packaging methods, and aren't allowed to update packages to use
>the recommended helper.

But as a team we do have only one officially sanctioned helper. The others
are deprecated. But okay, let's forget about that for now.

>Back on the VCS question, I fear that the 'all or nothing' road will circle
>back to 'nothing' for a long time. I think that we should allow some
>packages to live in git without forcing a complete migration, so individual
>maintainers can use the VCS they're more comfortable with. Most open source
>programmers have at least a basic familiarity with both, so it shouldn't be
>such an obstacle to working on other packages.
>
>We wouldn't be the only team doing this - Debian Games Team, for example,
>use both git and svn for packaging:
>http://wiki.debian.org/Games/VCS

As I said, I am against splitting team packages across different vcses. But
I'm also not the team BDFL (well, no one is :), so if I'm in the minority
opinion, so be it.

Cheers,
-Barry


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130214165...@anarchist.wooz.org

[Scott Kitterman]

On Thursday, February 14, 2013 04:53:23 PM Barry Warsaw wrote:
> On Feb 14, 2013, at 08:54 PM, Thomas Kluyver wrote:
> >I don't think it's a particularly good example, though. Lots of packages
> >continue to use the older helpers, and not due to a lack of time - attempts
> >to move away from the deprecated helpers still seem to meet considerable
> >resistance. That causes problems when newcomers don't want to learn
> >deprecated packaging methods, and aren't allowed to update packages to use
> >the recommended helper.
>
> But as a team we do have only one officially sanctioned helper. The others
> are deprecated. But okay, let's forget about that for now.
>
> >Back on the VCS question, I fear that the 'all or nothing' road will circle
> >back to 'nothing' for a long time. I think that we should allow some
> >packages to live in git without forcing a complete migration, so individual
> >maintainers can use the VCS they're more comfortable with. Most open source
> >programmers have at least a basic familiarity with both, so it shouldn't be
> >such an obstacle to working on other packages.
> >
> >We wouldn't be the only team doing this - Debian Games Team, for example,
> >use both git and svn for packaging:
> >http://wiki.debian.org/Games/VCS
>
> As I said, I am against splitting team packages across different vcses. But
> I'm also not the team BDFL (well, no one is :), so if I'm in the minority
> opinion, so be it.

Not splitting, IIRC, was the one thing that we had pretty solid consensus on
last time. There was considerable divergence about what VCS to not split
over, but I think most people agreed a common repository was something we
wanted.

Scott K

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1577886.oEELOcylCh@scott-latitude-e6320

[Piotr Ożarowski]

[Barry Warsaw, 2013-02-14]

> Switching to git or any other dvcs isn't going to happen just by asking for
> it. Someone would have to step up and actually do a lot of hard work to make
> it happen. Look at all the work done by upstream Python to get it onto
> Mercurial. It was *a lot* of work, making sure the conversions were high
> fidelity, that documentation was good, that the workflow made sense for the
> use cases, that newbies to distributed vcs were guided through the concepts
> and common practices, etc. etc. The folks who cared deeply about Mercurial
> made a long term commitment to ensuring a smooth transition. That was an
> argument that I lost, but I have to hand it to the winning side - minor rough
> edges and initial problems aside, it's a system that is working very well for
> the community today.
>
> So if some percentage of team members really really want to switch to git,
> step up and do enough of the work on spec (i.e. no guarantees) so that you
> have something that is convincing. It doesn't have to have all the rough
> edges polished off, but I do think it needs to very clearly demonstrate enough
> of a win over svn for the team (or a majority of them) that it would be a good
> switch. Please also do be respectful of the concerns of the detractors and
> opponents, and try to address them as best you can.

+1

I can help those who want to migrate all our packages to Git (as it's my
favourite VCS) and at the same time I (as an admin) will (and already
did in the past) ask anyone who doesn't keep a team package in SVN to
remove DPMT/PAPT from Maintainer/Uploaders (until we officially migrate
to something else).

One of the main points of these teams is to allow other members easy
access to debian directory / keep track of VCS changes (which I fail to
do lately, but did send some replies from -commits mailing list in the
past). Keeping package files somewhere where other team members might
not have write access or would have to do some extra work to find its
location is just not acceptable IMHO.

Providing a script (mr?) that will download/update all packages
(or only one of them, and no, debcheckout is not enough, think about
write access) from various VCSs using just one command might be an option
but only if top contributors (that sponsor uploads or commit changes
also in packages without their name in debian/control) don't mind using
it. [and please please please don't ask for such workflow without showing
the code]
--
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

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013021422...@piotro.eu

[Matthias Klose]

Am 14.02.2013 21:54, schrieb Thomas Kluyver:
> On 14 February 2013 20:29, Barry Warsaw <ba...@python.org> wrote:
>
>> I look at the switch to dh_python2 as an example.
>
>
> I don't think it's a particularly good example, though. Lots of packages
> continue to use the older helpers, and not due to a lack of time - attempts
> to move away from the deprecated helpers still seem to meet considerable
> resistance.

this is your interpretation. pycentral is deprecated for a long time [1]. There
are reasons to limit ourself to exactly one third-party directory [2], so maybe
that should be the broader goal for jessie.

> That causes problems when newcomers don't want to learn
> deprecated packaging methods, and aren't allowed to update packages to use
> the recommended helper.

Agreed, so why not helping with it? Again, why not helping here?

> Back on the VCS question, I fear that the 'all or nothing' road will circle
> back to 'nothing' for a long time. I think that we should allow some
> packages to live in git without forcing a complete migration, so individual
> maintainers can use the VCS they're more comfortable with. Most open source
> programmers have at least a basic familiarity with both, so it shouldn't be
> such an obstacle to working on other packages.
>
> We wouldn't be the only team doing this - Debian Games Team, for example,
> use both git and svn for packaging:
> http://wiki.debian.org/Games/VCS

Now you did point out one discrepancy, which hinders newcomers, and you do want
to introduce another one?

Matthias

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pycentral-deprecation;users=debian...@lists.debian.org
[2] https://lists.debian.org/debian-devel/2013/02/msg00109.html

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511D6B2...@debian.org

[Jakub Wilk]

* Piotr O�arowski <pi...@debian.org>, 2013-02-14, 23:49:

>One of the main points of these teams is to allow other members easy
>access to debian directory / keep track of VCS changes (which I fail to
>do lately, but did send some replies from -commits mailing list in the
>past). Keeping package files somewhere where other team members might
>not have write access or would have to do some extra work to find its
>location is just not acceptable IMHO.

+1

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013021423...@jwilk.net

[Thomas Kluyver]

On 14 February 2013 22:54, Matthias Klose <do...@debian.org> wrote:

> That causes problems when newcomers don't want to learn
> deprecated packaging methods, and aren't allowed to update packages to use
> the recommended helper.

Agreed, so why not helping with it? Again, why not helping here?

I'm not sure what you're suggesting I do. I consider myself to be a newcomer in more or less the situation I described. I've got better things to do than learn the workings of python-support, but switching a package to dh_python2 is apparently a major change, which only named maintainers can approve. And if the maintainers aren't interested, the old helper can remain indefinitely.

Also, between this sort of thing, and the tense atmosphere I sometimes feel this list has, I'm not especially motivated to contribute here. The effort/satisfaction ratio isn't as good as many other projects I can spend time on.

 

> Back on the VCS question, I fear that the 'all or nothing' road will circle
> back to 'nothing' for a long time. I think that we should allow some
> packages to live in git without forcing a complete migration, so individual
> maintainers can use the VCS they're more comfortable with. Most open source
> programmers have at least a basic familiarity with both, so it shouldn't be
> such an obstacle to working on other packages.
>
> We wouldn't be the only team doing this - Debian Games Team, for example,
> use both git and svn for packaging:
> http://wiki.debian.org/Games/VCS

Now you did point out one discrepancy, which hinders newcomers, and you do want
to introduce another one?

The distinction I was trying to make is that open source developers often already know the basics of multiple VCSs, because they've contribute to different projects. By contrast, the different packaging helpers are entirely specific to packaging Python modules within Debian, so newcomers have to learn them for this specific task. So there's less penalty to having multiple VCSs coexisting.

But I don't feel strongly about this point - it looks like we want to maintain a single team VCS, and that's fine by me.

Thomas

[Tristan Seligmann]

On Thu, Feb 14, 2013 at 5:08 PM, Thomas Goirand <zi...@debian.org> wrote:
> During these exchanges, I have already found that there's at least 4
> people (including myself) who would like to use Git. And that's without
> including all the members of the Openstack packaging team, who might
> also help. Do you think that we should form another Alioth project for
> that? Wouldn't that be silly? What are the alternatives that you see, if
> we are a lot of people willing to do python module team maintenance
> using Git?

I don't think forming a separate team would be silly at all. If you
have a group of people working on Python packages in Git, and a
separate group of people working on Python packages in SVN, what use
is there in pretending that they're the same group when they're
effectively separate anyway? Of course, there may be some people who
are interested in working on both teams, but there's nothing stopping
you being a member of both teams if you choose to do so.

When you say "I want to maintain my packages in Git, in the team",
there are really only two possible implications that I can see: 1) "I
want everyone in the team to comply with this way of doing things,
even though they don't want to do so", and 2) "I want to do things my
own way separate from the rest of the team, but claim to be working as
part of the team". Now, written that way, perhaps you can see why this
produces a negative reaction from some existing team members, even if
you did not mean it in that way?

The purpose of the team is to share the maintenance and infrastructure
burden for the packages included under the team's umbrella; when you
split that infrastructure, you effectively fork the team even if you
do not give the fork a new name. Such a fork naturally causes a
division of effort, but if you feel that Git vs. SVN makes enough of a
difference, then I see no reason why you shouldn't collaborate with
other people who feel the same way; it doesn't have to be a "hostile"
fork.
--
mithrandi, i Ainil en-Balandor, a faer Ambar

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAMcKhMSU-_0+ovjQRgFomKp3...@mail.gmail.com

[Dmitry Shachnev]

On Thu, Feb 14, 2013 at 10:54 PM, Thomas Goirand <zi...@debian.org> wrote:
> I believe there's some misunderstanding, so I must make it square.
> Again, I'm *not* asking for a full switch (or any switch at all) of all
> (or even some) packages of the python module team. I have *NEVER*
> written such thing, so could anyone writing in this tread refrain from
> switching to this topic? If you do want to talk about it (which would be
> a great move, IMO), do it in another thread, or at least not as a reply
> to my message.

I'm speaking about the same thing as you are. Having some packages is
SVN and some in Git (it's what you mean) will make it harder to do
mass-commits, mass-search and keeping up with others' changes.

Again, I prefer Git to SVN, but I agree with Barry, Scott and others
that divergence is *not* what we want.

--
Dmitry Shachnev

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAKimPHWBwrGH5=Z1sNMJYj+4oJfwqBf0...@mail.gmail.com

[Thomas Goirand]

On 02/15/2013 05:21 PM, Dmitry Shachnev wrote:
> On Thu, Feb 14, 2013 at 10:54 PM, Thomas Goirand <zi...@debian.org> wrote:
>> I believe there's some misunderstanding, so I must make it square.
>> Again, I'm *not* asking for a full switch (or any switch at all) of all
>> (or even some) packages of the python module team. I have *NEVER*
>> written such thing, so could anyone writing in this tread refrain from
>> switching to this topic? If you do want to talk about it (which would be
>> a great move, IMO), do it in another thread, or at least not as a reply
>> to my message.
>
> I'm speaking about the same thing as you are. Having some packages is
> SVN and some in Git (it's what you mean) will make it harder to do
> mass-commits, mass-search and keeping up with others' changes.
>
> Again, I prefer Git to SVN, but I agree with Barry, Scott and others
> that divergence is *not* what we want.
>
> --
> Dmitry Shachnev

So, should I open a new Alioth group for maintaining Python modules
collectively using Git?

Thomas

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511E1718...@debian.org

[Ansgar Burchardt]

On 02/15/2013 01:39, Tristan Seligmann wrote:
> I don't think forming a separate team would be silly at all. If you
> have a group of people working on Python packages in Git, and a
> separate group of people working on Python packages in SVN, what use
> is there in pretending that they're the same group when they're
> effectively separate anyway? Of course, there may be some people who
> are interested in working on both teams, but there's nothing stopping
> you being a member of both teams if you choose to do so.

I think having a separate team just to use another VCS is not good. It
will probably split contibutors between the different teams; having to
follow different polices (for the two teams) for similar packages would
at least annoy me.

pkg-perl had to make similar decisions in the past: all packages were
maintained in Subversion, but some people wanted to try out Git. This
was accepted even though some people said they might not care about the
Git packages, but it worked fairly well. (Eventually we switched to only
Git.)

Maybe a similar policy would work for the Python team as well? At least
if some regular contributors would have to be interested in using Git.

(I don't care too much as I only maintain a single package in the Python
modules team.)

> When you say "I want to maintain my packages in Git, in the team",
> there are really only two possible implications that I can see: 1) "I
> want everyone in the team to comply with this way of doing things,
> even though they don't want to do so", and 2) "I want to do things my
> own way separate from the rest of the team, but claim to be working as
> part of the team". Now, written that way, perhaps you can see why this
> produces a negative reaction from some existing team members, even if
> you did not mean it in that way?

There's more to maintaining packages in a team than having a common VCS.
For me it's fairly important to have people that you can ask questions,
one has a common policy for packages, ...

Ansgar

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/511E1D6...@debian.org

[Jakub Wilk]

* Piotr Ożarowski <pi...@debian.org>, 2013-02-14, 23:49:

>I (as an admin) will (and already did in the past) ask anyone who
>doesn't keep a team package in SVN to remove DPMT/PAPT from
>Maintainer/Uploaders (until we officially migrate to something else).

Please start with these (they declare Vcs-Git):

bugz
dajaxice
django-dajax
polib
pyjavaproperties
python-kyotocabinet
python-pgpdump
wokkel

and these (they don't use any VCS, AFAICS):

python-reportlab
python-w3lib

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013021820...@jwilk.net