Re: How does team maintenace of python module works?

[Thomas Goirand]

Tristan Seligmann wrote:
> I don't think forming a separate team would be silly at all.

I agree with absolutely all of what Ansgar wrote about this.

What is important is people doing the work, and being able to find
advices. In other words: team work.

> 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".

Oh! Are you *sure* this is what you think of me? It's quite shocking to
read that. It's not that at all. It's:

3) Upstream uses Git, and I have already lots of git things inside my
package and workflow (I already explained, I have no choice at all),
plus I know there's others willing to use Git, and not having the
possibility to do team work with them because of some member resisting
would be a bit silly.

It would be really stupid to only want to "claim" to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can, and receive help when I need, which is the point of a team.

I don't want to impose my workflow on anyone, you could continue to use
your current workflow if you like for the existing packages. I'm not at
all asking for a full switch. But the opposite isn't true, some members
of the team would like to impose the SVN workflow on me... or I should
just leave and maintain these packages on my own (or inside another
team)! Well, if I'm not allowed to use Git within the team, that's
exactly what is going to happen for these packages. And I think it's a
shame.

Tristan Seligmann wrote:
> 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?

If others see it that way, then they are missing the main point, which
is I have absolutely no choice of the VCS, given how much my packaging
work is intertwined with what upstream is using. Let me enumerate again:
signed pgp git tags (remember: I live in China, and China played with
man in the middle attacks with Github...), cherry-pick of patches, "git
merge -X theirs <tag-name>" for new release tags, "git ls-files" to
generate the MANIFEST.in, "git archive" to generate the orig.tar.xz, my
auto-builder script which is fully git based, using the upstream
repository for the master branch, etc. SVN or git-svn will not allow me
to do this.

I have absolutely no intention of disturbing the current workflow of the
team, I just want to have the possibility to do the work for these
packages where Git is convenient for me. I am ok to use SVN for the
*other* packages which I maintain / contribute already, but for some it
just wouldn't work. Note that I already did use SVN and pushed some
commits. And wish to add some more packages to the SVN (I just didn't
find out how yet... help would be appreciated so that I can push
python-testtools and python-fixtures!).

I do understand why some would like to keep a single VCS though. But
maybe it could be a more relaxed rule not written into a stone, where
some exceptions would be allowed at least. Recognizing that SVN doesn't
work in some cases (which I already explained above and in other posts)
would be a good step on the right direction IMHO.

Cheers,

Thomas Goirand (zigo)

P.S: I'm truly sorry for breaking the thread, I was reading through the
archive, but now I'm registered to the list. This will not happen again.


--
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/511F4D0C...@debian.org

[Thomas Kluyver]

On 16 February 2013 09:10, Thomas Goirand <zi...@debian.org> wrote:

It would be really stupid to only want to "claim" to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can, and receive help when I need, which is the point of a team.

I agree there are reasonable reasons to want to maintain something in git, and it's not ideal to exclude those packages from team maintainership just because of the VCS question. Although, if it came to that, the team would be happy to offer advice and assistance for Python packages that aren't maintained by the team. We all want stuff to work smoothly, whether or not it's "our" stuff.

I suggest we take a poll - not as a binding decision, but to get an idea of the level of support for different courses of action. You're free to attach more weight to the votes of highly involved team members.

The following four positions have all been advocated in this thread:

A - Maintain the status quo, in which DPMT packages may only be maintained in SVN.

B - As A, but encourage the creation of a separate team where Python modules can be maintained in git.

C - Allow DPMT-maintained packages to live in SVN or git, so new packages can be committed to git if the packager prefers. Optionally, we could make provisions to migrate existing packages.

D - Migrate all the DPMT-maintained packages to git.

(I suggest we don't consider other VCSs - while we might have our favourites, I sampled the list of Debian teams, and found very few using anything other than svn or git. So tools & workflows for other VCSs are likely to be less well developed.)

So I would vote CDBA, in order of preference.

Thanks,
Thomas

[Tristan Seligmann]

On Sat, Feb 16, 2013 at 11:10 AM, Thomas Goirand <zi...@debian.org> wrote:
> Oh! Are you *sure* this is what you think of me? It's quite shocking to
> read that. It's not that at all. It's:

It's what I think are the practical consequences of what you propose.

> team)! Well, if I'm not allowed to use Git within the team, that's
> exactly what is going to happen for these packages. And I think it's a
> shame.

But this is exactly the point; if team members are doing work in SVN,
then your packages in Git are not benefitting from this work.
Conversely, if you are doing work on the packages in Git, other
packages in SVN are not benefitting. Of course, there's nothing that
prevents you to ask for advice / commentary / whatever on the
debian-python mailing list regardless of whether you are discussing a
package maintained in DPMT/PAPT or not; you can also follow the team
guidelines in maintaining these packages if you so choose.

> If others see it that way, then they are missing the main point, which
> is I have absolutely no choice of the VCS, given how much my packaging
> work is intertwined with what upstream is using. Let me enumerate again:
> signed pgp git tags (remember: I live in China, and China played with
> man in the middle attacks with Github...), cherry-pick of patches, "git
> merge -X theirs <tag-name>" for new release tags, "git ls-files" to
> generate the MANIFEST.in, "git archive" to generate the orig.tar.xz, my
> auto-builder script which is fully git based, using the upstream
> repository for the master branch, etc. SVN or git-svn will not allow me
> to do this.

It certainly sounds like maintaining the packages in Git is a
reasonable choice here, and I don't have any reason to second-guess
your choices as maintainer; I just don't see how you hope to benefit
from maintaining the packages "in the team" when you aren't actually
making use of the team infrastructure that provides these benefits.
--
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/CAMcKhMSO=_oojDawLgsNwQ+L1pRMZ...@mail.gmail.com

[Scott Kitterman]

E - Migrated to bzr, but I want someone else to to all the work.

EA

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/1378953.kHPRnGo86U@scott-latitude-e6320

[Jakub Wilk]

* Scott Kitterman <deb...@kitterman.com>, 2013-02-16, 09:10:

>On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
>>The following four positions have all been advocated in this thread:
>>
>>A - Maintain the status quo, in which DPMT packages may only be
>>maintained in SVN.
>>B - As A, but encourage the creation of a separate team where Python
>>modules can be maintained in git.
>>C - Allow DPMT-maintained packages to live in SVN or git, so new
>>packages can be committed to git if the packager prefers. Optionally,
>>we could make provisions to migrate existing packages.
>>D - Migrate all the DPMT-maintained packages to git.
>>
>>(I suggest we don't consider other VCSs - while we might have our
>>favourites, I sampled the list of Debian teams, and found very few
>>using anything other than svn or git. So tools & workflows for other
>>VCSs are likely to be less well developed.)
>>
>>So I would vote CDBA, in order of preference.
>
>E - Migrated to bzr, but I want someone else to to all the work.
>
>EA

F - Migrate to Mercurial, but I want someone else to do all the work.

AF

--
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/2013021614...@jwilk.net

[Thomas Goirand]

On 02/16/2013 08:36 PM, Tristan Seligmann wrote:
> But this is exactly the point; if team members are doing work in SVN,
> then your packages in Git are not benefitting from this work.

Let's be practical for a bit.

Some members of the team already said they like to use Git.
So we wont have everyone using SVN, and just me, isolated,
using Git, in the world you describe above.

> Conversely, if you are doing work on the packages in Git, other
> packages in SVN are not benefitting.

I never wrote I would work *only* with Git, I wrote that it made
sense for some of the packages I maintain. I already sent
some updates in the SVN, and I do intend to do some more.
especially for Openstack dependencies (which is, a lot of
python modules...).

Using multiple VCSes may be simply just annoying. But not for
the reasons above.

On 02/16/2013 08:36 PM, Tristan Seligmann wrote:
> I just don't see how you hope to benefit
> from maintaining the packages "in the team" when you aren't actually
> making use of the team infrastructure that provides these benefits.

Simply because in the team, there's many different people,
and I'm sure some would happily contribute using Git. Just
like for the rest of Debian, it's voluntary based. I don't force
anyone, but accept any help. I just thought that this team
was the most relevant place to do so (and I still think it is).

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/511FDC29...@debian.org

[Dmitrijs Ledkovs]

On 16 February 2013 14:27, Jakub Wilk <jw...@debian.org> wrote:
> * Scott Kitterman <deb...@kitterman.com>, 2013-02-16, 09:10:
>>
>> On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
>>>
>>> The following four positions have all been advocated in this thread:
>>>
>>> A - Maintain the status quo, in which DPMT packages may only be
>>> maintained in SVN.
>>> B - As A, but encourage the creation of a separate team where Python
>>> modules can be maintained in git.
>>> C - Allow DPMT-maintained packages to live in SVN or git, so new packages
>>> can be committed to git if the packager prefers. Optionally, we could make
>>> provisions to migrate existing packages.
>>> D - Migrate all the DPMT-maintained packages to git.
>>>
>>> (I suggest we don't consider other VCSs - while we might have our
>>> favourites, I sampled the list of Debian teams, and found very few using
>>> anything other than svn or git. So tools & workflows for other VCSs are
>>> likely to be less well developed.)
>>>
>>> So I would vote CDBA, in order of preference.
>>
>>
>> E - Migrated to bzr, but I want someone else to to all the work.
>>
>> EA
>
>
> F - Migrate to Mercurial, but I want someone else to do all the work.
>

A, F.1 - Migrate to Mercurial, if and only if mercurial queues are
fully functional and are used to maintain the debian/patches
sub-repository.

realisticly i am opposed to a mix of version control systems.

someone to do the work - means starting a mirror which works in
read-only / mirror mode only.

When gnome.org was migrating from svn - they had multiple mirrors
running (bzr, and git, not sure if an hg was there as well)

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/CANBHLUjUfbFBnanRP2P9pu2M_PmmvEUWC5W4Byi=-Ns2H...@mail.gmail.com

[Daniele Tricoli]

On Saturday 16 February 2013 20:29:07 Dmitrijs Ledkovs wrote:
> A, F.1 - Migrate to Mercurial, if and only if mercurial queues are
> fully functional and are used to maintain the debian/patches
> sub-repository.
>
> realisticly i am opposed to a mix of version control systems.
>
> someone to do the work - means starting a mirror which works in
> read-only / mirror mode only.

I'm also for A, F.1 but my F option imply that I will help "to do the work"
:)

Cheers,

--
Daniele Tricoli 'Eriol'
http://mornie.org

[Robert Collins]

I will *always* have a soft spot in my heart for bzr, having spent
many years working on it.
But consider:

http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m&beenhere=1

If we're changing VCS, there is a vastly higher probability that the
folk whose software we are packaging is in git, and that contributors
we get will be familiar with git, than any other system now. That
doesn't mean git is better or worse, but if we're changing systems
because of preference (rather than fitness-for-purpose), then I think
we'd be crazy to consider any other VCS.

-Rob

--
Robert Collins <rbtco...@hp.com>
Distinguished Technologist
HP Cloud Services

--
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/CAJ3HoZ13=iiu1dBA=YQgsqZqvXHd0=2b=nyK6K8SX...@mail.gmail.com

[Dmitrijs Ledkovs]

Corrected url s/bazaar/bzr/ and disabled vote to make the graph lighter.

http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bzr&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

> If we're changing VCS, there is a vastly higher probability that the
> folk whose software we are packaging is in git, and that contributors
> we get will be familiar with git, than any other system now. That
> doesn't mean git is better or worse, but if we're changing systems
> because of preference (rather than fitness-for-purpose), then I think
> we'd be crazy to consider any other VCS.
>

svn is very alive and stable. I have managed in the past to crash or
otherwise make bzr/hg/git inconsistent. Some of my bugs got fixed and
mostly git is fit for purpose on the stability side of things.
I haven't used hg in a while. svn has always been good for me (but i
guess i'm a fairly recent developer and haven't seen the pre 1.5 days
of svn).

we are yet to figure out a packaging workflow that works great,
especially w.r.t. patch management. On one hand you want to simply
commit and merge, on the other hand you want to ship a patch series
for the convenience of dowstream/users, but that means rebasing, and
rebasing is pain to track history off, hence end up committing patches
but one wants to commit directly LOOPREACHED.

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/CANBHLUiMtS5AijZvZCUyE9Ya...@mail.gmail.com

[Scott Kitterman]

That was roughly my point. We all have our VCS preferences, but last time we
went through this topic, none of them other than SVN met all of the
requirements. I haven't seen anything in this thread to convince me that's
changed.

You'd also have to get some consensus around full source or debian directory
only branches. I don't think we can split on that either. Personally, I've
found nothing but frustration from trying to manage both Debian packaging and
upstream code in the same repository. I know other people have different
views, but that's been my experience.

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/1569034.rcGuYjMByi@scott-latitude-e6320

[Javi Merino]

On Sat, Feb 16, 2013 at 03:27:08PM +0100, Jakub Wilk wrote:
> * Scott Kitterman <deb...@kitterman.com>, 2013-02-16, 09:10:
> >On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
> >>The following four positions have all been advocated in this thread:
> >>
> >>A - Maintain the status quo, in which DPMT packages may only be
> >>maintained in SVN.
> >>B - As A, but encourage the creation of a separate team where
> >>Python modules can be maintained in git.
> >>C - Allow DPMT-maintained packages to live in SVN or git, so new
> >>packages can be committed to git if the packager prefers.
> >>Optionally, we could make provisions to migrate existing
> >>packages.
> >>D - Migrate all the DPMT-maintained packages to git.
> >>
> >>(I suggest we don't consider other VCSs - while we might have
> >>our favourites, I sampled the list of Debian teams, and found
> >>very few using anything other than svn or git. So tools &
> >>workflows for other VCSs are likely to be less well developed.)
> >>
> >>So I would vote CDBA, in order of preference.
> >
> >E - Migrated to bzr, but I want someone else to to all the work.
> >
> >EA
>
> F - Migrate to Mercurial, but I want someone else to do all the work.

The mercurial package is maintained in svn, mainly because it's part
of PAPT so it uses its infrastructure. But mercurial is quite popular in the
python world, as python itself is maintained in hg. Now being
realistic, the last time I looked at hg-buildpackage or
mercurial-buildpackage they were light years behind git-bp or svn-bp
so migrating to mercurial would be a lot more work than migrating to
git. I use a mixture of hgsubversion and proper subversion for mercurial
but I don't recommend it.

FCDAB

Cheers,
Javi

[Barry Warsaw]

On Feb 16, 2013, at 05:10 PM, Thomas Goirand wrote:

>3) Upstream uses Git, and I have already lots of git things inside my
>package and workflow (I already explained, I have no choice at all),
>plus I know there's others willing to use Git, and not having the
>possibility to do team work with them because of some member resisting
>would be a bit silly.

FWIW, the upstreams of the packages I maintain are in bzr, and I even maintain
packaging branches in bzr (mostly for purposes of testing). It's not *that*
hard to switch gears and work in svn, but that might be because for me at
least, bzr and svn are matches than git and svn.

>If others see it that way, then they are missing the main point, which
>is I have absolutely no choice of the VCS, given how much my packaging
>work is intertwined with what upstream is using.

This is true across the board though, and it has nothing to do with git. I
regularly run into upstreams that use all three dvcses, *and* svn, *and*
(thankfully much more rare now) cvs.

I understand that it's difficult to shift down into svn when you have a
workflow and toolchain that is so specifically geared to git. But OTOH, we're
just talking about the debian/ directories in the team svn repo, so is it
really that difficult to stick with svn for that directory? (I agree that we
could probably improve the documentation on how to do so effectively.)

-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/20130216180...@anarchist.wooz.org

[Barry Warsaw]

On Feb 16, 2013, at 05:51 PM, Scott Kitterman wrote:

>You'd also have to get some consensus around full source or debian directory
>only branches. I don't think we can split on that either.

Agreed!

>Personally, I've found nothing but frustration from trying to manage both
>Debian packaging and upstream code in the same repository. I know other
>people have different views, but that's been my experience.

And I'm just the opposite, but I might be only one of a dozen people in the
world who actually uses bzr source branches daily, and likes them. :)

OTOH, there's no doubt there are rough edges. Heck, I would even support a
transition to git if the workflow were largely similar to Ubuntu's source
branches, but with better quilt integration. To me, something like that is my
packaging nirvana.

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/20130216181...@anarchist.wooz.org

[Chow Loong Jin]

On 17/02/2013 07:10, Barry Warsaw wrote:
> [...]

> OTOH, there's no doubt there are rough edges. Heck, I would even support a
> transition to git if the workflow were largely similar to Ubuntu's source
> branches, but with better quilt integration. To me, something like that is my
> packaging nirvana.

git-buildpackage has gbp-pq which works pretty nicely. I've been using it for a
while now.

--
Kind regards,
Loong Jin

[Ludovic Gasc]

I vote D, and I can handle the migration from SVN to Git, I've done this several times for my work and WYMeditor.

Are you interested?

[Thomas Kluyver]

On 18 February 2013 20:46, Ludovic Gasc <gml...@gmail.com> wrote:

I vote D, and I can handle the migration from SVN to Git, I've done this several times for my work and WYMeditor.

Are you interested?

I'm interested personally, but the votes so far suggest there's no real will for any change - the only option with more than one first preference vote is the status quo.

Thomas

[Ludovic Gasc]

I propose to make a poll on the Web (Doodle or other) and ask the question in another thread, I'm not sure that each subscriber has read this long thread.

 

Thomas

[Jakub Wilk]

* Ludovic Gasc <gml...@gmail.com>, 2013-02-18, 23:23:

>I propose to make a poll on the Web (Doodle or other) and ask the
>question in another thread, I'm not sure that each subscriber has read
>this long thread.

And then, if the results are still unsatisfactory, let's create a repo
at GitHub and let people vote via pull requests. (SNCR)

--
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/2013021822...@jwilk.net

[Thomas Kluyver]

On 18 February 2013 22:23, Ludovic Gasc <gml...@gmail.com> wrote:

I propose to make a poll on the Web (Doodle or other) and ask the question in another thread, I'm not sure that each subscriber has read this long thread.

I don't think I'll do that myself - the responses I have seen don't have even the barest hint of consensus, and there's no particular reason to think that a wider sample would produce a more unified opinion. If you think it would be useful, though, I shan't stop you doing it.

Thomas

[Thomas Goirand]

On 02/19/2013 06:08 AM, Thomas Kluyver wrote:
> On 18 February 2013 20:46, Ludovic Gasc <gml...@gmail.com

> <mailto:gml...@gmail.com>> wrote:
>
> I vote D, and I can handle the migration from SVN to Git, I've
> done this several times for my work and WYMeditor.
>
> Are you interested?
>
> I'm interested personally, but the votes so far suggest there's no
> real will for any change - the only option with more than one first
> preference vote is the status quo.
>
> Thomas

So far, those who could have vote C or D (this shows in previous reply
that some could have voted that) didn't bother answering the "poll".
Probably because of the tone of some participants of this thread, who
didn't take it seriously, replied unrealistic answers who were not even
in the original poll, or discussed previously in the thread.It would
probably have been more efficient to just read previous contribution in
this thread, if some of the participants just ran away from it...

It seems that there's a will to completely destroy this discussion
anyway (which is quite successful), so don't expect much from now on.
I just hope not too many people will read this shameful thread.

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/5123B24D...@debian.org

[Dmitry Shachnev]

On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand <zi...@debian.org> wrote:
> So far, those who could have vote C or D (this shows in previous reply
> that some could have voted that) didn't bother answering the "poll".

I've already expressed my opinion in this thread, but to be formal: my
vote is DA.

--
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/CAKimPHW-GhRj1w99NaOgLifE...@mail.gmail.com

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand <zi...@debian.org> wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev

Mine is CDAB.

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/5123B93B...@debian.org

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:

> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand <zi...@debian.org> wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev
>
>

I have reviewed (I hope, MOST) answers, and here's what I get:

Scott K

E - Migrated to bzr, but I want someone else to to all the work.

Jakub Wilk

F - Migrate to Mercurial, but I want someone else to do all the work.

Dmitrijs
DA

Daniele Tricoli

A, F.1 but my F option imply that I will help "to do the work"

Robert Collins
Seems to want to allow Git

Barry Warsaw
Likes BZR, but seems to possibly agree with git on some workflow conditions

Chow Loong Jin
Didn't express himself, but knows how to use git and git-buildpackage

Javi Merino
FCDAB

Ludovic Gasc
D

Thomas Kluyver
Seems to be ok with migrating to Git (so, option D)

Myself:
CDBA

So, we have 12 persons who expressed themselves, about 6 persons
who would agree with Git in some ways, 3 who would like to move
to another system, but if they don't do the work. We also have
2 persons who proposed themselves for doing the work of moving
to Git.

If the above isn't correct, please let everyone know your view.

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/5123BC84...@debian.org

[Piotr Ożarowski]

FTR: I want to migrate to Git, but I don't have time to do the migration
work right now, so I vote for status quo (unless someone will show me
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

[Andreas Noteng]

Den 19. feb. 2013 18:55, skreiv Thomas Goirand:
> If the above isn't correct, please let everyone know your view. Thomas

My contribution to this team is relatively low volume, but anyways: My
vote is, in order of preference, DCAB. I'd also be happy with bzr (which
I use for my Ubuntu stuff), but IMHO git is the most useable vcs for
Debian packaging.

Regards
Andreas Noteng

--
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/5123E646...@noteng.no

[Charlie Smotherman]

On Tue, Feb 19, 2013 at 3:42 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote:

> On 19 February 2013 17:55, Thomas Goirand <zi...@debian.org> wrote:
>>
>> Thomas Kluyver
>> Seems to be ok with migrating to Git (so, option D)
>
>

> I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for
> summarising the votes.
>
> Including Piotr & Andreas, and putting people whose opinion you've described
> into the nearest possible vote would give us first preference votes:
>
> D: 4 (migration to git)
> C: 3 (allow git)
> E: 2 (migration to bzr)
> F: 2 (migration to hg)
> A: 1 (maintain status quo) - I thought there were some more, but I'm too
> tired to go back through the thread at present.
>
> Using alternative voting, knock out A (and B, which had no first preference
> votes):
>
> D: 4
> C: 3
> F: 3
> E: 2
>
> After that it gets tricky, because we'd knock E out next, but the I'm not
> sure where the votes counted for E (Scott & Barry) should be reallocated. If
> we plough ahead regardless by dropping them, it ends up with a 4-4 draw
> between D (migration to git) and C (allowing git and svn). Perhaps we can
> get more votes, or more fallback preferences from people who've only
> expressed their first preference.
>
> Thomas

here is my $.02 worth
EA

--
Charlie Smotherman

--
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/CAL_XWdB9VLUDb70S4txVm4sV...@mail.gmail.com

[Thomas Kluyver]

On 19 February 2013 17:55, Thomas Goirand <zi...@debian.org> wrote:

Thomas Kluyver
Seems to be ok with migrating to Git (so, option D)

[Robert Collins]

I didn't vote initiall because I read the below as a summary...

On 17 February 2013 01:43, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
> On 16 February 2013 09:10, Thomas Goirand <zi...@debian.org> wrote:
>>
>> It would be really stupid to only want to "claim" to be working as part
>> of the team, that's not at all what I want to do. I'd like to be able to
>> help when I can, and receive help when I need, which is the point of a
>> team.
>
>
> I agree there are reasonable reasons to want to maintain something in git,
> and it's not ideal to exclude those packages from team maintainership just
> because of the VCS question. Although, if it came to that, the team would be
> happy to offer advice and assistance for Python packages that aren't
> maintained by the team. We all want stuff to work smoothly, whether or not
> it's "our" stuff.
>
> I suggest we take a poll - not as a binding decision, but to get an idea of
> the level of support for different courses of action. You're free to attach
> more weight to the votes of highly involved team members.
>
> The following four positions have all been advocated in this thread:
>
> A - Maintain the status quo, in which DPMT packages may only be maintained
> in SVN.
> B - As A, but encourage the creation of a separate team where Python modules
> can be maintained in git.
> C - Allow DPMT-maintained packages to live in SVN or git, so new packages
> can be committed to git if the packager prefers. Optionally, we could make
> provisions to migrate existing packages.
> D - Migrate all the DPMT-maintained packages to git.

DCA

-Rob


--
Robert Collins <rbtco...@hp.com>
Distinguished Technologist
HP Cloud Services

--
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/CAJ3HoZ0r_ssuS4ukGYWpaqFq...@mail.gmail.com

[Barry Warsaw]

On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:

>After that it gets tricky, because we'd knock E out next, but the I'm not
>sure where the votes counted for E (Scott & Barry) should be reallocated.

If it makes things easier, I am essentially sided with Piotr. The fact that I
don't like git much is immaterial - I want a dvcs and don't have the time to
put into a bzr or hg migration. I don't have time to put into a git migration
either, but it seems like you've got that covered. :)

So I still think it comes down to, them that does the work gets to decide, but
there *is* work to do. It's clear we don't want multiple vcses. So I think
you have an opportunity to convince us by:

* Doing a test migration and putting a test repo up so we can play with it and
see what it's like.

* Figure out whether full-source or debian/ only works better (maybe give us
both repos so we can play with them and discuss the pros and cons from
actual working examples).

* Put together draft policy and documentation to describe a workflow for team
maintenance of packages under git, including branching, pull requests, code
review, quilt integration, package building, etc.

* Work out how upstreams that are under other vcses would work.

* Provide a plan for a smooth flag day transition if/when consensus is reached.

* Gather feedback, fix problems, rinse and repeat.

Once people are comfortable with how a git-based team repository would work, I
suspect you'll find more consensus to switch.

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/20130219172...@anarchist.wooz.org

[Daniele Tricoli]

On Tuesday 19 February 2013 23:20:48 Barry Warsaw wrote:
> If it makes things easier, I am essentially sided with Piotr. The fact
> that I don't like git much is immaterial - I want a dvcs and don't have
> the time to put into a bzr or hg migration. I don't have time to put
> into a git migration either, but it seems like you've got that covered.
> :)

[CUT: I agree with remaining paragraphs]

I'm agree with Barry, although I don't like git, it doesn't matter, I will
simply learn git better if it's the best tool for us :)

--
Daniele Tricoli 'Eriol'
http://mornie.org

--
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/201302200001...@mornie.org

[Piotr Ożarowski]

[Barry Warsaw, 2013-02-19]

> So I still think it comes down to, them that does the work gets to decide, but
> there *is* work to do. It's clear we don't want multiple vcses. So I think
> you have an opportunity to convince us by:
>
> * Doing a test migration and putting a test repo up so we can play with it and
> see what it's like.
>
> * Figure out whether full-source or debian/ only works better (maybe give us
> both repos so we can play with them and discuss the pros and cons from
> actual working examples).
>
> * Put together draft policy and documentation to describe a workflow for team
> maintenance of packages under git, including branching, pull requests, code
> review, quilt integration, package building, etc.
>
> * Work out how upstreams that are under other vcses would work.
>
> * Provide a plan for a smooth flag day transition if/when consensus is reached.
>
> * Gather feedback, fix problems, rinse and repeat.
>
> Once people are comfortable with how a git-based team repository would work, I
> suspect you'll find more consensus to switch.

+1

/me will point to this mail every time someone proposes to switch to $foo

[Ludovic Gasc]

On Feb 19, 2013 11:21 PM, "Barry Warsaw" <ba...@python.org> wrote:
>
> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>
> >After that it gets tricky, because we'd knock E out next, but the I'm not
> >sure where the votes counted for E (Scott & Barry) should be reallocated.
>
> If it makes things easier, I am essentially sided with Piotr.  The fact that I
> don't like git much is immaterial - I want a dvcs and don't have the time to
> put into a bzr or hg migration.  I don't have time to put into a git migration
> either, but it seems like you've got that covered. :)
>
> So I still think it comes down to, them that does the work gets to decide, but
> there *is* work to do.  It's clear we don't want multiple vcses.  So I think
> you have an opportunity to convince us by:
>
> * Doing a test migration and putting a test repo up so we can play with it and
>   see what it's like.

I can do that this week-end. I've only a github account to publish the git repository, unless somebody else has an access for a better place? For a test, I think that github is enough.

>
> * Figure out whether full-source or debian/ only works better (maybe give us
>   both repos so we can play with them and discuss the pros and cons from
>   actual working examples).

A tool that we could use in the future to maintain the packages with more ease: https://honk.sigxcpu.org/piki/projects/git-buildpackage/

[Matthias Klose]

Am 20.02.2013 00:53, schrieb Piotr Ożarowski:
> [Barry Warsaw, 2013-02-19]
>> So I still think it comes down to, them that does the work gets to
>> decide, but there *is* work to do. It's clear we don't want multiple
>> vcses. So I think you have an opportunity to convince us by:
>>
>> * Doing a test migration and putting a test repo up so we can play with
>> it and see what it's like.
>>
>> * Figure out whether full-source or debian/ only works better (maybe give
>> us both repos so we can play with them and discuss the pros and cons
>> from actual working examples).
>>
>> * Put together draft policy and documentation to describe a workflow for
>> team maintenance of packages under git, including branching, pull
>> requests, code review, quilt integration, package building, etc.
>>
>> * Work out how upstreams that are under other vcses would work.
>>
>> * Provide a plan for a smooth flag day transition if/when consensus is
>> reached.
>>
>> * Gather feedback, fix problems, rinse and repeat.
>>
>> Once people are comfortable with how a git-based team repository would
>> work, I suspect you'll find more consensus to switch.
>
> +1

can we limit the packages in this ppa to those using dh_python[23] and those
supporting python3?

Matthias

--
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/512416B2...@debian.org

[Scott Kitterman]

On Tuesday, February 19, 2013 05:20:48 PM Barry Warsaw wrote:
> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
> >After that it gets tricky, because we'd knock E out next, but the I'm not
> >sure where the votes counted for E (Scott & Barry) should be reallocated.
>
> If it makes things easier, I am essentially sided with Piotr. The fact that
> I don't like git much is immaterial - I want a dvcs and don't have the time
> to put into a bzr or hg migration. I don't have time to put into a git
> migration either, but it seems like you've got that covered. :)

What I don't have is time to relearn git every time I'm forced to use it. I'm
not sure the advantages of a team outweigh that for me.

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/16809265.qMvuDupsD3@scott-latitude-e6320

[Thomas Goirand]

On 02/20/2013 06:20 AM, Barry Warsaw wrote:
> * Figure out whether full-source or debian/ only works better (maybe give us
> both repos so we can play with them and discuss the pros and cons from
> actual working examples).

What is important, I believe, is that git-buildpackage always works.

I've found that having a debian/rules entry called "get-vcs-source"
which gets what is needed from upstream works quite nicely. Our
workflow is described here:

http://openstack.alioth.debian.org/

The idea to use "git archive" was mostly from Julien Danjou. It's
very nice because that way, we can use xz compression, instead
of what upstream provides (that is, github .zip or .tar.gz, which
isn't the best). It's also quite nice because that way, it's possible
to tag a specific commit and package that as upstream release.
This is mostly why I think using Git is convenient, so I really would
like this to be part of the draft.

Though this workflow only works if upstream uses Git, which isn't
the case. In other cases, probably using a pristine tar branch
would do.

BTW, I of course agree that it's 100% necessary to make sure we
have a unified policy, including on branch names and all. For branch
names, I've used the following:

- debian-sid
- upstream-sid
- debian-squeeze
- upstream-squeeze
- etc.

But also:

- debian/unstable
- debian/experimental
- master

then I used the tags from the master branch.

I think it's ok to have both naming shemes. The important bit,
IMO, is that everything is referenced in the debian/gbp.conf so
that nobody has to second-guess what to do.

Just my 2 cents, and if help is needed for migrating, I hope to
be able to be available if you ask.

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/51244FA6...@debian.org

[Scott Kitterman]

On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
> The idea to use "git archive" was mostly from Julien Danjou. It's
> very nice because that way, we can use xz compression, instead
> of what upstream provides (that is, github .zip or .tar.gz, which
> isn't the best).

See devref 6.7.8. This not an appropriate reason to not use the upstream
tarball.

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/3161329.3ERJUKFsNh@scott-latitude-e6320

[Scott Kitterman]

On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:

This all seems to assume full source branches which is not something I'm
interested in participating in at all. I've tried it and I find it very
difficult to work with.

Currently we have one VCS and one package layout. In the end, we should have
that still. Anything else raises a substantial barrier to collaboration.

Scott K

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/20321216.BZ1nqtJvkm@scott-latitude-e6320

[Thomas Goirand]

On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> This all seems to assume full source branches which is not something I'm
> interested in participating in at all. I've tried it and I find it very
> difficult to work with.
>
> Currently we have one VCS and one package layout. In the end, we should have
> that still. Anything else raises a substantial barrier to collaboration.
>
> Scott K

Would you care explaining why full source branches is difficult to work
with?

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/51248A7D...@debian.org

[Thomas Goirand]

On 02/20/2013 12:38 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
>> The idea to use "git archive" was mostly from Julien Danjou. It's
>> very nice because that way, we can use xz compression, instead
>> of what upstream provides (that is, github .zip or .tar.gz, which
>> isn't the best).
> See devref 6.7.8. This not an appropriate reason to not use the upstream
> tarball.
>
> Scott K

Thanks Scott, but I believe I know what I'm doing. This wasn't the
only reason I stated, it's only one of the consequences.

What upstream considers "release tarballs" are *not* what Github
provides anyway (it is a little bit more complex than this).

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/512489EB...@debian.org

[Luca BRUNO]

Thomas Goirand scrisse:

> I've found that having a debian/rules entry called "get-vcs-source"
> which gets what is needed from upstream works quite nicely. Our
> workflow is described here:
>
> http://openstack.alioth.debian.org/
>
> The idea to use "git archive" was mostly from Julien Danjou. It's
> very nice because that way, we can use xz compression, instead
> of what upstream provides (that is, github .zip or .tar.gz, which
> isn't the best). It's also quite nice because that way, it's possible
> to tag a specific commit and package that as upstream release.
> This is mostly why I think using Git is convenient, so I really would
> like this to be part of the draft.

This may suit well for the openstack scenario, however in general I
could see at least two shortcomings:
* pristine upstream tarballs are not used (see the first "should" in
devref §6.7.8.2)
* it assumes that no tarball generation process (eg. make dist) is
needed

I'm not sure how much impact they have on normal python-team workflow,
though.

Cheers, Luca

--
.''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~
: :' : | Email: lucab (AT) debian.org ~ Debian Developer
`. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter
`- | HAM-radio callsign: IZ1WGT ~ Networking sorcerer

[Thomas Goirand]

On 02/20/2013 04:31 PM, Luca BRUNO wrote:
> This may suit well for the openstack scenario, however in general I
> could see at least two shortcomings:
> * pristine upstream tarballs are not used (see the first "should" in
> devref §6.7.8.2)
> * it assumes that no tarball generation process (eg. make dist) is
> needed
>
> I'm not sure how much impact they have on normal python-team workflow,
> though.
>
> Cheers, Luca

I agree it only fits cases where upstream uses git and tags.
Though it's a more and more common case. Some upstream
authors don't even care to release a tarball at all nowadays.

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/51248EC5...@debian.org

[Matthias Klose]

Am 20.02.2013 09:31, schrieb Thomas Goirand:
> On 02/20/2013 12:38 PM, Scott Kitterman wrote:
>> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
>>> The idea to use "git archive" was mostly from Julien Danjou. It's
>>> very nice because that way, we can use xz compression, instead
>>> of what upstream provides (that is, github .zip or .tar.gz, which
>>> isn't the best).
>> See devref 6.7.8. This not an appropriate reason to not use the upstream
>> tarball.
>>
>> Scott K
> Thanks Scott, but I believe I know what I'm doing.

No, I don't think so.

> This wasn't the
> only reason I stated, it's only one of the consequences.
>
> What upstream considers "release tarballs" are *not* what Github
> provides anyway (it is a little bit more complex than this).

So there would be no way anymore to build using upstream tarballs? This doesn't
sound appropriate to force on a whole team.

I don't think that many of the people that voted are aware of your implicit
changes (no release tarballs, including upstream source in the VCS) by moving to
git.

Matthias

--
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/51248FDF...@debian.org

[Thomas Goirand]

On 02/20/2013 04:57 PM, Matthias Klose wrote:
> So there would be no way anymore to build using upstream tarballs?

Upstream tarballs, in some cases, is a concept of the past. When
they are released (sometimes, they simply don't exist), it may only
an image based on a git tag. Then using Git tags is often better,
because tags may be PGP signed. I live in China, and the Chinese
government did twice some man in the middle attack... Tarballs
don't include PGP signatures. Plus it's possible for me to tag at
any point in time, any commit, and use that to generate a tarball.

Signed git tags is the new trend, you shouldn't fear it, and stick
to the old 1980's concepts forever, only because we always did
this way.

If sticking to our old habits is not the only valid point, that there
are real technical reasons why we should never be using a git tag
as the key for an upstream release, or if you think they might be
real difference between the "git archive" generated xz file and the
github/gitorious/etc. tag based tar.gz, please explain.

> This doesn't sound appropriate to force on a whole team.

Of course it's not. In fact, I don't think it's the right thing to do to
impose rules set that strong, and write them into a stone. There's
no "one size fit all", and such a rigidity may bring inconvenience.

I by the way think that switching everything from SVN to Git will
probably be painful for a lot of the team members, which is why
I think it isn't a so good idea, and that best would have been to
allow both even if I understand why using more than one VCS
might be at least annoying and probably very inconvenient
sometimes.

This doesn't mean that we shouldn't try to define some standards,
and try to stick with them whenever possible, but only to some
reasonable extend.

Also, if you have valid arguments to use one type of workflow, and
if it really is convenient to work the way you tell, I will happily adopt
your way. Please share your view, and packaging habits and tricks!

My intention when describing our workflow was to give ideas, and
confront them. If everyone shares, I'm sure this will be beneficial.

> I don't think that many of the people that voted are aware of your implicit
> changes (no release tarballs, including upstream source in the VCS) by moving to
> git.
>
> Matthias

Once more, I never wanted to change anything in the team,
I just wanted to be allowed to use Git when relevant. I voted
CDBA, in this order, as I didn't wish to distrub anyone that
likes SVN.

Now, do you know if it is possible to use git-buildpackage
without storing the full upstream source in a branch? I never
did that way. For me, using git-buildpackage is mandatory, it
is simply too convenient. What is the problem of storing
upstream source code anyway (that's the 2nd time I ask,
as nobody explained yet why it's a problem)?

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/5124DA42...@debian.org

[Barry Warsaw]

On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:

>If sticking to our old habits is not the only valid point, that there
>are real technical reasons why we should never be using a git tag
>as the key for an upstream release, or if you think they might be
>real difference between the "git archive" generated xz file and the
>github/gitorious/etc. tag based tar.gz, please explain.

You better be darn sure that upstream has excellent QA then, and that you know
for sure that a tag is correctly assigned to a buildable, tested, QA passed
snapshot of the project. Also, you must ensure that everything necessary to
build and deploy the package is either included in the repository or is easily
generated by something that is in the repository. I bet that's going to cover
a minority of projects still. At least with a tarball, you know you have a
releasable "thing" that upstream has blessed (which could still have problems,
sure, but that's different than not being sure.)

Look at it from a Debian Python packager's point of view. If it's on PyPI,
then there's no guessing. If it's a git tag in some repo, you have to carry
along much more implicit context (e.g. the workflow of the upstream project,
do I have the right repo, etc.).

It's also not true that tarballs can't be signed, they are all the time on
PyPI. Maybe not as often as we'd like, but still.

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/20130220092...@anarchist.wooz.org

[Scott Kitterman]

On Wednesday, February 20, 2013 04:34:05 PM Thomas Goirand wrote:
> On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> > This all seems to assume full source branches which is not something I'm
> > interested in participating in at all. I've tried it and I find it very
> > difficult to work with.
> >
> > Currently we have one VCS and one package layout. In the end, we should
> > have that still. Anything else raises a substantial barrier to
> > collaboration.
> >
> > Scott K
>
> Would you care explaining why full source branches is difficult to work
> with?

First, full source repositories are much larger than debian only repositories.
I don't have a full checkout of all team packages locally, so that means if
I'm going to touch a package I don't have to download, it's more time,
bandwidth, etc. Even for a new upstream version, debian directory in the
repository and upstream tarball is still smaller.

Second, I think Debian packaging work and upstream's product should be
distinct in the source package. The source package is what Debian as a
project ships as the source for DFSG purposes and it should be useful.
"Here's a huge mass of code and to understand what we did to it, you need to
refer to this external repository (VCS)" is not socially acceptable to me.

Third, I have yet to see a workflow for maintaining debian/patches in a VCS as
part of a full source branch that was not more work than just having the
patches in a debian/patches and letting dpkg handle getting them applied/
unapplied.

Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to figure
out a workflow that integrates all those just seems impossible.

I've used partial (debian dir) VCS branches for years in both Debian and
Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at all
to full source.

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/1460350.rKONIhgERt@scott-latitude-e6320

[Simon McVittie]

On 20/02/13 14:14, Thomas Goirand wrote:
> Now, do you know if it is possible to use git-buildpackage
> without storing the full upstream source in a branch?

Yes, most conveniently done via 'overlay = True' in debian/gbp.conf. You
have to supply a copy of the upstream tarball as you would for plain
debuild or svn-buildpackage, typically in .. or ../tarballs (also
configurable in gbp.conf).

I do this for openarena-data and its various related packages, because
the full upstream source is *huge* (mostly audio, graphics etc.),
particularly once I included the actual source files, so keeping a copy
in git would be a significant problem; and the upstream source is
unlikely to ever be patched in Debian (not that binary files patch well
anyway), so there's no point.

I don't think debian-directory-only maintenance in git is a good idea
for typical packages containing "mostly" code - you lose the ability to
use gbp-pq to manage patches, for instance. openarena and ioquake3 do
have an 'upstream' branch, using the typical git-buildpackage workflow.

S

--
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/5124E066...@debian.org

[Thomas Goirand]

On 02/20/2013 10:23 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>
>> If sticking to our old habits is not the only valid point, that there
>> are real technical reasons why we should never be using a git tag
>> as the key for an upstream release, or if you think they might be
>> real difference between the "git archive" generated xz file and the
>> github/gitorious/etc. tag based tar.gz, please explain.
> You better be darn sure that upstream has excellent QA then, and that you know
> for sure that a tag is correctly assigned to a buildable, tested, QA passed
> snapshot of the project.

In what way the QA is different because it's a tag instead of a tarball ?
I don't understand your reasoning. In both cases, you must make sure
that what you are packaging is buildable, tested, QA, etc.

> Also, you must ensure that everything necessary to
> build and deploy the package is either included in the repository or is easily
> generated by something that is in the repository. I bet that's going to cover
> a minority of projects still. At least with a tarball, you know you have a
> releasable "thing" that upstream has blessed (which could still have problems,
> sure, but that's different than not being sure.)
>
> Look at it from a Debian Python packager's point of view. If it's on PyPI,
> then there's no guessing. If it's a git tag in some repo, you have to carry
> along much more implicit context (e.g. the workflow of the upstream project,
> do I have the right repo, etc.).

With many PiPY projects, I can see that the generated tarball are the
exact same thing as what's tagged in the Git repository. Often, the
release process is automated so the tag and the tarball are released
at once. This has been the case, for example, for:

- python-pecan (https://github.com/dreamhost/pecan)
- python-json-patch (https://github.com/stefankoegl/python-json-patch)
- python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
- python-tablib (https://github.com/kennethreitz/tablib)
- cliff-tablib (https://github.com/dreamhost/cliff-tablib)
- python-warlock (https://github.com/bcwaldon/warlock)

(non exhaustive list... and not including all of Openstack!)

I don't understand your reasoning, they are all using setuptools, and
are perfectly buildable, installable, etc. Did I miss something?

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/5124E387...@debian.org

[Scott Kitterman]

On Wednesday, February 20, 2013 10:14:26 PM Thomas Goirand wrote:
> Upstream tarballs, in some cases, is a concept of the past. When
> they are released (sometimes, they simply don't exist), it may only
> an image based on a git tag. Then using Git tags is often better,
> because tags may be PGP signed. I live in China, and the Chinese
> government did twice some man in the middle attack... Tarballs
> don't include PGP signatures. Plus it's possible for me to tag at
> any point in time, any commit, and use that to generate a tarball.

In some cases, sure. For me, every package I maintain has a tarball release
and most, if not all, provide signatures for the tarball. GPG signed is not
an advantage for git tags. Anything can be signed.

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/24754993.i0WrSetHUW@scott-latitude-e6320

[Thomas Kluyver]

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

In what way the QA is different because it's a tag instead of a tarball ?
I don't understand your reasoning. In both cases, you must make sure
that what you are packaging is buildable, tested, QA, etc.

I think the idea is that, if you prepare a release and find some last-minute critical bug (say, in the build process), you'll definitely upload a fixed release tarball, because that's what people are installing from. But you might have already tagged it, and you might forget to move the tag to the fixed version.

Of course, in projects where the git tag is the release, it makes no difference. But lots of projects still do tag a release and upload separate release tarballs (say, to PyPI).

Thomas

[Barry Warsaw]

On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote:

>> You better be darn sure that upstream has excellent QA then, and that you
>> know for sure that a tag is correctly assigned to a buildable, tested, QA
>> passed snapshot of the project.
>
>In what way the QA is different because it's a tag instead of a tarball ?
>I don't understand your reasoning. In both cases, you must make sure
>that what you are packaging is buildable, tested, QA, etc.

Right, but it's a matter of context. If you have a release on PyPI, you know
it's been blessed. You don't need any more context. For a git tag, I have to
know what is the blessed repo url, how the tagging scheme works, what the
latest releasable snapshot is tagged, etc. I need much more context to know
what is "a release" (even though upstream might find them quaint, Debian still
does releases of packages, i.e. uploads). What if the repo url changes? What
if they start using a different tagging scheme? What if someone accidentally
assigned a release tag to a non-releasable revision?

That might not be so important for someone who has intimate and ongoing
knowledge of package maintenance, but it's really important for team
maintained packages where I might have to fix a bug or grab a new upstream for
a package you primarily maintain.

>> Look at it from a Debian Python packager's point of view. If it's on PyPI,
>> then there's no guessing. If it's a git tag in some repo, you have to carry
>> along much more implicit context (e.g. the workflow of the upstream project,
>> do I have the right repo, etc.).
>
>With many PiPY projects, I can see that the generated tarball are the
>exact same thing as what's tagged in the Git repository. Often, the
>release process is automated so the tag and the tarball are released
>at once. This has been the case, for example, for:
>
>- python-pecan (https://github.com/dreamhost/pecan)
>- python-json-patch (https://github.com/stefankoegl/python-json-patch)
>- python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
>- python-tablib (https://github.com/kennethreitz/tablib)
>- cliff-tablib (https://github.com/dreamhost/cliff-tablib)
>- python-warlock (https://github.com/bcwaldon/warlock)

That's great, but I bet it's a minority of projects on PyPI.

>(non exhaustive list... and not including all of Openstack!)
>
>I don't understand your reasoning, they are all using setuptools, and
>are perfectly buildable, installable, etc. Did I miss something?

The point is, I might not want or have the time to know all the intimate
details about how upstream does its project management. It will certainly be
an impediment to collective, team maintenance.

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/20130220100...@anarchist.wooz.org

[Thomas Goirand]

On 02/20/2013 10:43 PM, Scott Kitterman wrote:
> First, full source repositories are much larger than debian only repositories.
> I don't have a full checkout of all team packages locally, so that means if
> I'm going to touch a package I don't have to download, it's more time,
> bandwidth, etc. Even for a new upstream version, debian directory in the
> repository and upstream tarball is still smaller.

If you are modifying some packages, it's to upload them at some point.
In such case, you will need the upstream tarball, right? I don't see where
the waste of bandwidth is then.

> Second, I think Debian packaging work and upstream's product should be
> distinct in the source package. The source package is what Debian as a
> project ships as the source for DFSG purposes and it should be useful.

Which is why we have branches. One with the upstream code, and one
with the debian folder added. Everything being contained in that debian
folder. So it's really distinct.

> "Here's a huge mass of code and to understand what we did to it, you need to
> refer to this external repository (VCS)" is not socially acceptable to me.

It's not any different to have absolutely zero upstream code in the VCS:
you will need to refer to an upstream tarball, which has "a huge mass
of code".

> Third, I have yet to see a workflow for maintaining debian/patches in a VCS as
> part of a full source branch that was not more work than just having the
> patches in a debian/patches and letting dpkg handle getting them applied/
> unapplied.

Having full source branches do not prevent you from using debian/patches.
I use that often, together with dpkg-source --commit and friends. If you
have
in debian/gbp.conf the following:

[git-buildpackage]
export-dir = ../build-area/

patches are applied/unapplied by git-buildpackage automatically at build
time,
in a separate folder, which doesn't pollute your VCS tree. So I'd say
it's the same,
with the added benefit of being able to use upstream commits to generate
diffs.

> Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to figure
> out a workflow that integrates all those just seems impossible.

For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and
hg-fast-export).
If that doesn't work, you can use the pristine-tar thing, that should
always work.
I never used it, probably I should learn, it seems quite convenient. Can
anyone
give feedback about it?

By the way, I do the packaging of MLMMJ, and upstream provides both
mercurial
and Git, which I think is really awesome. If we could have that, and not
only Git,
that would be best, IMO, so that those who likes hg could use it. Last
time I
looked, it didn't seem so hard to setup. Probably that would be a nice
addition
to Alioth as well, so that any Alioth project using Mercurial would have
Git too.
Do you also think it would be worth asking the Fusion Forge team?

> I've used partial (debian dir) VCS branches for years in both Debian and
> Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at all
> to full source.

WIthout full source, how do you use git-buildpackage? Could you describe
your workflow so that I can understand your view as well?

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/5124EA80...@debian.org

[Scott Kitterman]

On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
> > First, full source repositories are much larger than debian only
> > repositories. I don't have a full checkout of all team packages locally,
> > so that means if I'm going to touch a package I don't have to download,
> > it's more time, bandwidth, etc. Even for a new upstream version, debian
> > directory in the repository and upstream tarball is still smaller.
>
> If you are modifying some packages, it's to upload them at some point.
> In such case, you will need the upstream tarball, right? I don't see where
> the waste of bandwidth is then.

A VCS with all the upstream history will always be bigger than the tarball for
just the current release. Sometimes substantially so.

> > Second, I think Debian packaging work and upstream's product should be
> > distinct in the source package. The source package is what Debian as a
> > project ships as the source for DFSG purposes and it should be useful.
>
> Which is why we have branches. One with the upstream code, and one
> with the debian folder added. Everything being contained in that debian
> folder. So it's really distinct.

You're missing my point. If it's only in the VCS, it's not in the source
package. The source package needs to stand alone without the VCS to, in my
opinion, properly comply with the spirit of the DFSG.

> > "Here's a huge mass of code and to understand what we did to it, you need
> > to refer to this external repository (VCS)" is not socially acceptable to
> > me.
> It's not any different to have absolutely zero upstream code in the VCS:
> you will need to refer to an upstream tarball, which has "a huge mass
> of code".

Right, but if you embed Debian specific changes and don't use patches (as I've
seen some people do who use Git) then any Debian changes to the upstream code
are difficult to parse and undocumented. When you have patches, they are
documented in debian/changelog and in the patch comments exactly why they are
there (I know sometimes this isn't done, but it is supposed to be).

> > Third, I have yet to see a workflow for maintaining debian/patches in a
> > VCS as part of a full source branch that was not more work than just
> > having the patches in a debian/patches and letting dpkg handle getting
> > them applied/ unapplied.
>
> Having full source branches do not prevent you from using debian/patches.
> I use that often, together with dpkg-source --commit and friends. If you
> have in debian/gbp.conf the following:
>
> [git-buildpackage]
> export-dir = ../build-area/
>
> patches are applied/unapplied by git-buildpackage automatically at build
> time,
> in a separate folder, which doesn't pollute your VCS tree. So I'd say
> it's the same,
> with the added benefit of being able to use upstream commits to generate
> diffs.
>
> > Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to
> > figure out a workflow that integrates all those just seems impossible.
>
> For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and
> hg-fast-export).
> If that doesn't work, you can use the pristine-tar thing, that should
> always work.
> I never used it, probably I should learn, it seems quite convenient. Can
> anyone
> give feedback about it?

I've had it explained to me how to do it, done it, and then the next time I
needed to do it could no longer remember it. For people that do packaging all
day, every day, I think many of these tools are great, but for people like me
for whom this is not the main focus of their day there's too much complexity
involved to be useful.

> By the way, I do the packaging of MLMMJ, and upstream provides both
> mercurial
> and Git, which I think is really awesome. If we could have that, and not
> only Git,
> that would be best, IMO, so that those who likes hg could use it. Last
> time I
> looked, it didn't seem so hard to setup. Probably that would be a nice
> addition
> to Alioth as well, so that any Alioth project using Mercurial would have
> Git too.
> Do you also think it would be worth asking the Fusion Forge team?
>
> > I've used partial (debian dir) VCS branches for years in both Debian and
> > Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
> > all to full source.
>
> WIthout full source, how do you use git-buildpackage? Could you describe
> your workflow so that I can understand your view as well?

I don't. I generally unpack the upstream tarball, export the debian dir from
the VCS into the unpacked tarball, update the package, build it with dpkg-
buildpackage, and then commit the changes back to the VCS repository with
debcommit (which is very nice since it speaks to multiple VCS through the same
interface).

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/2022623.hNdOdV0QLB@scott-latitude-e6320

[Thomas Goirand]

On 02/20/2013 11:09 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote:
>
>>> You better be darn sure that upstream has excellent QA then, and that you
>>> know for sure that a tag is correctly assigned to a buildable, tested, QA
>>> passed snapshot of the project.
>> In what way the QA is different because it's a tag instead of a tarball ?
>> I don't understand your reasoning. In both cases, you must make sure
>> that what you are packaging is buildable, tested, QA, etc.
> Right, but it's a matter of context. If you have a release on PyPI, you know
> it's been blessed. You don't need any more context. For a git tag, I have to
> know what is the blessed repo url, how the tagging scheme works, what the
> latest releasable snapshot is tagged, etc. I need much more context to know
> what is "a release" (even though upstream might find them quaint, Debian still
> does releases of packages, i.e. uploads). What if the repo url changes? What
> if they start using a different tagging scheme? What if someone accidentally
> assigned a release tag to a non-releasable revision?

For the packages which I worked on, there was always a Git URL in PiPY,
and I didn't have any of the issues you're talking about above. I'm not
saying it can ever happen, but only that I see no difference with making
a tarball: in both cases, you can do mistakes, can't find the correct
URL and have it changed, etc. I haven't yet met a "context" problem like
you describe above, but truth, I have seen multiple tagging scheme, the
most reoccurring one being to add a "v" in front of the version number
(which is easily worked around in the gbp.conf).

> That might not be so important for someone who has intimate and ongoing
> knowledge of package maintenance, but it's really important for team
> maintained packages where I might have to fix a bug or grab a new upstream for
> a package you primarily maintain.

Team members can read debian/copyright, where you have the Source: field.

>> With many PiPY projects, I can see that the generated tarball are the
>> exact same thing as what's tagged in the Git repository. Often, the
>> release process is automated so the tag and the tarball are released
>> at once. This has been the case, for example, for:
>>
>> - python-pecan (https://github.com/dreamhost/pecan)
>> - python-json-patch (https://github.com/stefankoegl/python-json-patch)
>> - python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
>> - python-tablib (https://github.com/kennethreitz/tablib)
>> - cliff-tablib (https://github.com/dreamhost/cliff-tablib)
>> - python-warlock (https://github.com/bcwaldon/warlock)
> That's great, but I bet it's a minority of projects on PyPI.

Like you, I have no stats available, so I can't tell. But for me, that
was a vast
majority of the packages I worked on.

Anyway, I'm not asking anyone to follow my workflow, I was merely explaining
what I've been doing, and what I was very happy with. It might indeed only
work for a group of packages only.

Do you guys think we should only have *one type* of workflow? I wouldn't
mind switching to some different way of doing things if the team finds it
relevant, and if it is more easy and unified across all packages. If so,
please tell how you would like to work. We would loose most of the cool
features I was used to, but so be it...

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/512504BF...@debian.org

[Piotr Ożarowski]

[Thomas Goirand, 2013-02-20]

> I wouldn't
> mind switching to some different way of doing things if the team finds it
> relevant, and if it is more easy and unified across all packages. If so,
> please tell how you would like to work. We would loose most of the cool
> features I was used to, but so be it...

does git-buildpackage work with git submodules (with debian dir as a
separate git repo)?

[Thomas Goirand]

On 02/20/2013 11:45 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
>>> First, full source repositories are much larger than debian only
>>> repositories. I don't have a full checkout of all team packages locally,
>>> so that means if I'm going to touch a package I don't have to download,
>>> it's more time, bandwidth, etc. Even for a new upstream version, debian
>>> directory in the repository and upstream tarball is still smaller.
>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth is then.
> A VCS with all the upstream history will always be bigger than the tarball for
> just the current release. Sometimes substantially so.

But you only very rarely clone from scratch, and only get some
incremental changes.
While with tarballs, you always have to get the full of it.

>
>>> Second, I think Debian packaging work and upstream's product should be
>>> distinct in the source package. The source package is what Debian as a
>>> project ships as the source for DFSG purposes and it should be useful.
>> Which is why we have branches. One with the upstream code, and one
>> with the debian folder added. Everything being contained in that debian
>> folder. So it's really distinct.
> You're missing my point. If it's only in the VCS, it's not in the source
> package. The source package needs to stand alone without the VCS to, in my
> opinion, properly comply with the spirit of the DFSG.

It's funny that you say it this way. I've read some other opinion saying
that with the
tarball, you're missing lots of information from upstream. That person
went up to
say that he thought it'd be a good idea to package the git repository as
source
package (sorry, I can't remember who and when, just that it was in
-de...@l.d.o).
I quite agree with this view.

>>> "Here's a huge mass of code and to understand what we did to it, you need
>>> to refer to this external repository (VCS)" is not socially acceptable to
>>> me.
>> It's not any different to have absolutely zero upstream code in the VCS:
>> you will need to refer to an upstream tarball, which has "a huge mass
>> of code".
> Right, but if you embed Debian specific changes and don't use patches

That's not what I do.

> I know sometimes this isn't done, but it is supposed to be

I agree it's a bad idea, so we are on the same line.

> I generally unpack the upstream tarball, export the debian dir from
> the VCS into the unpacked tarball, update the package, build it with dpkg-
> buildpackage, and then commit the changes back to the VCS repository with
> debcommit (which is very nice since it speaks to multiple VCS through the same
> interface).

So, basically, you're doing all by hand... That's very tedious. IMO, the
whole
point of using git (or any other VCS), is to use either git-buildpackage, or
"git-stuff" (that's a package name...), so you have tools to do all this
manual
boring work. git-stuff works the opposite way. You'd do all the changes in
your packaging, then it would write the debian/changelog based on the
commit messages. I find it a lot better, because then you can have a history
of you changes, do rebase, squashes, cancel, etc. without the risk to loose
any of your changes.

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/51250A67...@debian.org

[Andreas Noteng]

Den 20. feb. 2013 16:23, skreiv Thomas Goirand:
> If that doesn't work, you can use the pristine-tar thing, that should
> always work.
> I never used it, probably I should learn, it seems quite convenient. Can
> anyone
> give feedback about it?
>

My workflow for anything outside of this team and not intended for
Ubuntu directly is with git and a full source branch. I don't package
often enough to remember everything from time to time, but it's no more
than a quick google search away. Roughly the workflow is to use uscan to
download the source tarball, git-import-orig with pristine tar to import
upstream code into upstream branch. git-import-orig handles committing
an tagging necessary changes. Using quilt I can then modyfi anything I
like in the source directories, and quilt will keep every change in the
debian/patches folder. If I accidentally touch anything not handled by
quilt this is easily reverted with a single-file checkout. When I'm
happy with the changes I build the package using git-buildpackage
(--git-ignore-new if I want to test before commit)
--git-builder=pdebuild. Once I'm ready to upload the debian release
commit is tagged. Because of pristine tar, the upstream release tarball
can be recreated from the upstream branch, and everybody should be happy.

IMHO patching and patch handling is way easier in git than in svn,
mostly because I never copy or export anything to create and test the
patches. I totally agree that all changes to the source should be kept
as patches.

Regards
Andreas Noteng

--
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/512506C1...@noteng.no

[Scott Kitterman]

Thomas Goirand <zi...@debian.org> wrote:

>On 02/20/2013 11:45 PM, Scott Kitterman wrote:
>> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
>>>> First, full source repositories are much larger than debian only
>>>> repositories. I don't have a full checkout of all team packages
>locally,
>>>> so that means if I'm going to touch a package I don't have to
>download,
>>>> it's more time, bandwidth, etc. Even for a new upstream version,
>debian
>>>> directory in the repository and upstream tarball is still smaller.
>>> If you are modifying some packages, it's to upload them at some
>point.
>>> In such case, you will need the upstream tarball, right? I don't see
>where
>>> the waste of bandwidth is then.
>> A VCS with all the upstream history will always be bigger than the
>tarball for
>> just the current release. Sometimes substantially so.
>
>But you only very rarely clone from scratch, and only get some
>incremental changes.
>While with tarballs, you always have to get the full of it.

I don't keep local copies of things I don't work on regularly, so for team packages I would be downloading all of it.

Right. Someday there may be a source format git, but until then ...

I've done the boring bits enough that my fingers mostly do them without much attention from my brain. If I were going to abandon my current approach, I'd have to see significant advantages for a new way and I don't.

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/609b9744-397f-46a0...@email.android.com

[Nicolas Chauvat]

On Wed, Feb 20, 2013 at 06:43:11PM +0100, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-02-20]
> > I wouldn't
> > mind switching to some different way of doing things if the team finds it
> > relevant, and if it is more easy and unified across all packages. If so,
> > please tell how you would like to work. We would loose most of the cool
> > features I was used to, but so be it...
>
> does git-buildpackage work with git submodules (with debian dir as a
> separate git repo)?

FWIW, there is probably a way to implement the same idea with
mercurial's subrepo or guestrepo.

http://mercurial.selenic.com/wiki/Subrepository
http://mercurial.selenic.com/wiki/GuestrepoExtension

PS: No, I don't have time to do the work, hence I just mention it exists.

--
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances

--
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/20130220214...@volans.logilab.fr

[Dmitrijs Ledkovs]

On 19 February 2013 23:49, Ludovic Gasc <gml...@gmail.com> wrote:

>
> On Feb 19, 2013 11:21 PM, "Barry Warsaw" <ba...@python.org> wrote:
>>
>> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>>
>

> I can do that this week-end. I've only a github account to publish the git
> repository, unless somebody else has an access for a better place? For a
> test, I think that github is enough.
>

Using github would be against the basic principles laid out in the
Debian Social Contract.
While gitorious hosted solution, would be ok it reimplements the git
server & protocol and hence lacks many features.
It is best to continue to use excellent hosting facilities provided by
git.debian.org / alioth.debian.org.
One can create repositories in a home directory (please don't use
official team account / group names) which would be good enough for
maintainance.

Having an gerrit instance would help a lot to serve merge requests
functionality.

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/CANBHLUgvhb5fv3SRj+DOjSvi...@mail.gmail.com

[Chow Loong Jin]

On 21/02/2013 01:43, Piotr Ożarowski wrote:
> does git-buildpackage work with git submodules (with debian dir as a
> separate git repo)?

It should. I wrote the initial patch for submodule support in git-buildpackage.

--
Kind regards,
Loong Jin

[Chow Loong Jin]

On 20/02/2013 23:45, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:

> [...]

>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth is then.
>
> A VCS with all the upstream history will always be bigger than the tarball for
> just the current release. Sometimes substantially so.

Not always. Text compresses easily, so it is not uncommon for the .git to be
smaller than a single uncompressed checkout of the tarball. And with
pristine-tar, you end up having every single tarball in history contained in
that .git directory.

>>> Second, I think Debian packaging work and upstream's product should be
>>> distinct in the source package. The source package is what Debian as a
>>> project ships as the source for DFSG purposes and it should be useful.
>>
>> Which is why we have branches. One with the upstream code, and one
>> with the debian folder added. Everything being contained in that debian
>> folder. So it's really distinct.
>
> You're missing my point. If it's only in the VCS, it's not in the source
> package. The source package needs to stand alone without the VCS to, in my
> opinion, properly comply with the spirit of the DFSG.

In the pkg-cli-{apps,libs}, we keep upstream history separate from downstream
history. Only the tarballs are imported, and that is done using git import-orig
--pristine-tar. Patches are maintained using gbp-pq or quilt. At the end of the
day, there isn't anything that only lives in the VCS.

>>> "Here's a huge mass of code and to understand what we did to it, you need
>>> to refer to this external repository (VCS)" is not socially acceptable to
>>> me.
>> It's not any different to have absolutely zero upstream code in the VCS:
>> you will need to refer to an upstream tarball, which has "a huge mass
>> of code".
>
> Right, but if you embed Debian specific changes and don't use patches (as I've
> seen some people do who use Git) then any Debian changes to the upstream code
> are difficult to parse and undocumented. When you have patches, they are
> documented in debian/changelog and in the patch comments exactly why they are
> there (I know sometimes this isn't done, but it is supposed to be).

Actually, with git-buildpackage, there's a gbp-pq tool which allows you to
import a quilt series of patches into a temporary patch-queue/$branch in git,
allowing you to use git rebase and whatever other git tools you have to figure
out what changes go where. After which, they can be exported into debian/patches
again and committed.

> [...]

> I've had it explained to me how to do it, done it, and then the next time I
> needed to do it could no longer remember it. For people that do packaging all
> day, every day, I think many of these tools are great, but for people like me
> for whom this is not the main focus of their day there's too much complexity
> involved to be useful.

That argument applies to any VCS that you don't use on a daily basis. You use
bzr on a daily basis and forget how to use git. I use git on a daily basis and
forget how to use svn/bzr and have to relearn it any time someone forces me to
use one of those. I don't think this is a valid reason for avoiding git.

>> By the way, I do the packaging of MLMMJ, and upstream provides both
>> mercurial
>> and Git, which I think is really awesome. If we could have that, and not
>> only Git,
>> that would be best, IMO, so that those who likes hg could use it. Last
>> time I
>> looked, it didn't seem so hard to setup. Probably that would be a nice
>> addition
>> to Alioth as well, so that any Alioth project using Mercurial would have
>> Git too.
>> Do you also think it would be worth asking the Fusion Forge team?
>>
>>> I've used partial (debian dir) VCS branches for years in both Debian and
>>> Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
>>> all to full source.
>>
>> WIthout full source, how do you use git-buildpackage? Could you describe
>> your workflow so that I can understand your view as well?
>
> I don't. I generally unpack the upstream tarball, export the debian dir from
> the VCS into the unpacked tarball, update the package, build it with dpkg-
> buildpackage, and then commit the changes back to the VCS repository with
> debcommit (which is very nice since it speaks to multiple VCS through the same
> interface).

That sounds like awful lot of steps to take. My workflow only involves editing
things directly in the git repository, and then running git-buildpackage to
build. With the export-dir option that I have set in ~/.gbp.conf, that
automatically exports it out to ../build-area/ and builds on the spot.
Committing can be done with debcommit or any other method of committing into a
git repository.

[Chow Loong Jin]

On 21/02/2013 01:59, Scott Kitterman wrote:
> I've done the boring bits enough that my fingers mostly do them without much
> attention from my brain. If I were going to abandon my current approach, I'd
> have to see significant advantages for a new way and I don't.

Somehow I can only read this as: "I've done things manually all this while and
it works for me, so go away and don't bother me because I don't see any
advantages in having things automated."

[Barry Warsaw]

On Feb 21, 2013, at 11:08 AM, Chow Loong Jin wrote:

>That argument applies to any VCS that you don't use on a daily basis. You use
>bzr on a daily basis and forget how to use git. I use git on a daily basis and
>forget how to use svn/bzr and have to relearn it any time someone forces me to
>use one of those. I don't think this is a valid reason for avoiding git.

As you say, this is true of any tool you use only intermittently. Here's a
fairly good example of the kind of documentation that I think helps bridge the
gap. It's for Python developers using the Mercurial repo, but it's more than
that. It describes the common hg commands in the context of the workflow that
core Python committers use.

http://docs.python.org/devguide/committing.html

I can never remember how to do a null merge, but this section answers the
question nicely:

http://docs.python.org/devguide/committing.html?highlight=null%20merge#porting-within-a-major-version

Cheers,
-Barry

[Scott Kitterman]

If the automation actually made things easier, I'd be in favor of it. I used
to manually tag uploads in svn for DPMT/PAPT because I didn't trust svn-
buildpackage. Then I learned it a bit better and started using it because it
was easier. Then I learned debcommit -r -R and it was even easier.

I'm all for easy. I have yet to see a full source (regardless of VCS) or git
workflow that I didn't find more complex and harder to remember/do correctly
than what we have now. I really don't care about what the new hotness is. It
actually needs to be better and not just cooler. For me, a lot of better is
simpler.

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/1662015.k84YxWKh5C@scott-latitude-e6320

[Chow Loong Jin]

On 21/02/2013 11:58, Scott Kitterman wrote:
> On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
>> On 21/02/2013 01:59, Scott Kitterman wrote:
>>> I've done the boring bits enough that my fingers mostly do them without
>>> much attention from my brain. If I were going to abandon my current
>>> approach, I'd have to see significant advantages for a new way and I
>>> don't.
>>
>> Somehow I can only read this as: "I've done things manually all this while
>> and it works for me, so go away and don't bother me because I don't see any
>> advantages in having things automated."
>
> If the automation actually made things easier, I'd be in favor of it. I used
> to manually tag uploads in svn for DPMT/PAPT because I didn't trust svn-
> buildpackage. Then I learned it a bit better and started using it because it
> was easier. Then I learned debcommit -r -R and it was even easier.
>
> I'm all for easy. I have yet to see a full source (regardless of VCS) or git
> workflow that I didn't find more complex and harder to remember/do correctly
> than what we have now. I really don't care about what the new hotness is. It
> actually needs to be better and not just cooler. For me, a lot of better is
> simpler.

Update package:
- edit
- debcommit -a
- git buildpackage (--git-builder="sbuild -d $distribution")

Tagging:
- git buildpackage --git-tag (or --git-tag-only if you've already built)

Import new orig tarball:
- git import-orig $tarball

Cloning repository:
- gbp-clone git://git.debian.org/….git

Updating repository:
- gbp-pull

Looks simple enough to me. How much simpler do you want it?

[Scott Kitterman]

On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
...

> That argument applies to any VCS that you don't use on a daily basis. You
> use bzr on a daily basis and forget how to use git. I use git on a daily
> basis and forget how to use svn/bzr and have to relearn it any time someone
> forces me to use one of those. I don't think this is a valid reason for
> avoiding git.

...

It is to a degree, but the learning curve for git is subtantially steeper than
for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and
there is no question in my mind which one, by a lot, is the most complex to
learn.

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/2027781.JVGg8X73QH@scott-latitude-e6320

[Chow Loong Jin]

On 21/02/2013 12:02, Scott Kitterman wrote:
> It is to a degree, but the learning curve for git is subtantially steeper than
> for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and
> there is no question in my mind which one, by a lot, is the most complex to
> learn.

I'll admit that git isn't the simplest one, the others are not perfect either.
To this day, I can't for the life of me figure out how to use CVS. Thank
goodness git-cvsimport works.

SVN is simple enough, but so is git when used with only linear history. But
let's not forget the horrible hack that is svn tagging/branching.

Bzr is simple enough as well, but $deity help you when you get incompatible pack
format repositories, or when bzr suddenly decides that your branches have
diverged for no apparent reason whatsoever. At least with git, you know when
you've rewritten history -- you're no longer on the same commit.

[Barry Warsaw]

On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:

>It is to a degree, but the learning curve for git is subtantially steeper
>than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or
>another and there is no question in my mind which one, by a lot, is the most
>complex to learn.

No one's accusing git of actually being user friendly. <wink>

http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

-Barry

[Barry Warsaw]

On Feb 21, 2013, at 12:15 PM, Chow Loong Jin wrote:

>I'll admit that git isn't the simplest one, the others are not perfect either.
>To this day, I can't for the life of me figure out how to use CVS. Thank
>goodness git-cvsimport works.

Of course, CVS is 20+ years old so its ancient model is working against you.

>SVN is simple enough, but so is git when used with only linear history. But
>let's not forget the horrible hack that is svn tagging/branching.

True, but also not much of a mental stretch when you realize it's just
creating new directories in the repo.

>Bzr is simple enough as well, but $deity help you when you get incompatible
>pack format repositories

Mostly not an issue any more, since 2a format has been the only sane format to
use for a few years now. Yes, you do run into old branch formats now and
then. Sigh.

>, or when bzr suddenly decides that your branches have diverged for no
>apparent reason whatsoever.

I agree with this one. It's a real problem with UDD when you have both an
upstream branch (e.g. lp:foo) and a packaging branch (e.g. ubuntu:foo).

>At least with git, you know when you've rewritten history -- you're no longer
>on the same commit.

#9 on Steve Bennett's list is right on target IMHO, but I've had this
discussion so many times before, I don't have much energy for it again.

"""
9. Git history is a bunch of lies
The primary output of development work should be source code. Is a
well-maintained history really such an important by-product? Most of the
arguments for rebase, in particular, rely on aesthetic judgments about “messy
merges” in the history, or “unreadable logs”. So rebase encourages you to lie
in order to provide other developers with a “clean”, “uncluttered”
history. Surely the correct solution is a better log output that can filter
out these unwanted merges.
"""

Cheers,
-Barry

[Scott Kitterman]

With git (I've never used gpb, and maybe that's my problem) I end up having to
do things like:

git clone git://git.debian.org/….git
for branch in pristine-tar debian/unstable ; do git branch --track $branch
origin/$branch ; done

That's the sort of thing that convinces me it's too hard. The fact that I
have to manually make the association between individual local and remove
branches is just insane.

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/4940572.qY1k9Flhxp@scott-latitude-e6320

[Paul Wise]

On Thu, Feb 21, 2013 at 12:37 PM, Scott Kitterman wrote:

> That's the sort of thing that convinces me it's too hard. The fact that I
> have to manually make the association between individual local and remove
> branches is just insane.

This has changed with git from experimental, it sets up the
association by default for remote branches and gives you an option to
turn it off or turn it on for local branches too. Theres an option to
set branches to use rebase by default too.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
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/CAKTje6H9N-sAggBHr6TydeDd...@mail.gmail.com

[Thomas Goirand]

Some of the points in this page are really wrong.
Like in the point 6, 7, 8 and 9, the author didn't understand
at all the necessity of having fast-forward history when
a project scales up, with lots of contributors.

Then finally, I agree, the only thing that remains is the
complexity. :)

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/5125B737...@debian.org

[Chow Loong Jin]

(Re-posted back on list. Sorry ScottK.)

On 21/02/2013 12:37, Scott Kitterman wrote:
> With git (I've never used gpb, and maybe that's my problem) I end up having to
> do things like:
>
> git clone git://git.debian.org/….git
> for branch in pristine-tar debian/unstable ; do git branch --track $branch
> origin/$branch ; done
>
> That's the sort of thing that convinces me it's too hard. The fact that I
> have to manually make the association between individual local and remove
> branches is just insane.

That's what gbp-clone does for you -- it clones, and creates
master/pristine-tar/upstream. pristine-tar is the most important, because if
this branch isn't present then git-buildpackage silently builds a brand new
tarball for you.

Aside from that, git (as of 1.7.10.4, not sure when it was introduced) also
automatically does that set up for you when you git checkout $branch where
$branch doesn't exist but origin/$branch does.

[Scott Kitterman]

On Wednesday, February 20, 2013 11:46:31 PM Barry Warsaw wrote:
> >At least with git, you know when you've rewritten history -- you're no
> >longer on the same commit.
>
> #9 on Steve Bennett's list is right on target IMHO, but I've had this
> discussion so many times before, I don't have much energy for it again.
>
> """
> 9. Git history is a bunch of lies
> The primary output of development work should be source code. Is a
> well-maintained history really such an important by-product? Most of the
> arguments for rebase, in particular, rely on aesthetic judgments about
> “messy merges” in the history, or “unreadable logs”. So rebase encourages
> you to lie in order to provide other developers with a “clean”,
> “uncluttered” history. Surely the correct solution is a better log output
> that can filter out these unwanted merges.
> """

Agreed.

I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to
be able to find it 4 years later).

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/4870622.bsvUB0WW7U@scott-latitude-e6320

[Charles Plessy]

Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a �crit :

> On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
> ...
> > That argument applies to any VCS that you don't use on a daily basis. You
> > use bzr on a daily basis and forget how to use git. I use git on a daily
> > basis and forget how to use svn/bzr and have to relearn it any time someone
> > forces me to use one of those. I don't think this is a valid reason for
> > avoiding git.
> ...
>
> It is to a degree, but the learning curve for git is subtantially steeper than
> for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and
> there is no question in my mind which one, by a lot, is the most complex to
> learn.

Dear Scott,

I undertand that learning Git after BZR is hard, because learning BZR after Git
is equally painful. I think that the key difficulty is whether a system is
learned first or second, not the system itself.

This is where git-buildpackage is nice, as it re-implements the same user experience
as with svn-buildpackage, and therefore provides some kind of upgrade path.

Cheers,

--
Charles Plessy

--
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/2013022106...@falafel.plessy.net

[Chow Loong Jin]

On 21/02/2013 12:46, Barry Warsaw wrote:
> #9 on Steve Bennett's list is right on target IMHO, but I've had this
> discussion so many times before, I don't have much energy for it again.
>
> """
> 9. Git history is a bunch of lies
> The primary output of development work should be source code. Is a
> well-maintained history really such an important by-product? Most of the
> arguments for rebase, in particular, rely on aesthetic judgments about “messy
> merges” in the history, or “unreadable logs”. So rebase encourages you to lie
> in order to provide other developers with a “clean”, “uncluttered”
> history. Surely the correct solution is a better log output that can filter
> out these unwanted merges.
> """

Well, rebasing aside, my main reason for rewriting history is to ensure that
each commit is properly separated so that if I ever need something specific
reverted, I can just git revert and take out that particular change instead of
having to pick aside the appropriate change from inside the commit. git-bisect
also works a lot better if your commits are "clean" and "uncluttered".

[Scott Kitterman]

On Thursday, February 21, 2013 03:00:56 PM Charles Plessy wrote:

> Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit :
> > On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
> > ...
> >
> > > That argument applies to any VCS that you don't use on a daily basis.
> > > You
> > > use bzr on a daily basis and forget how to use git. I use git on a daily
> > > basis and forget how to use svn/bzr and have to relearn it any time
> > > someone
> > > forces me to use one of those. I don't think this is a valid reason for
> > > avoiding git.
> >
> > ...
> >
> > It is to a degree, but the learning curve for git is subtantially steeper
> > than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or
> > another and there is no question in my mind which one, by a lot, is the
> > most complex to learn.
>
> Dear Scott,
>
> I undertand that learning Git after BZR is hard, because learning BZR after
> Git is equally painful. I think that the key difficulty is whether a
> system is learned first or second, not the system itself.
>
> This is where git-buildpackage is nice, as it re-implements the same user
> experience as with svn-buildpackage, and therefore provides some kind of
> upgrade path.

I disagree. Learning git is harder than all the others. It doesn't matter
what order you learn them in. If you look at the figures in point 10 of
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ (you can
largely substitute bzr for svn there and it won't get any more complex) and
tell me those are of equal complexity.

For all it's power, the git U/I is just inconsistent and counter intuitive.
If you use it routinely, you get so you remember it and it seems easy. If you
don't, you have to re-climb up the learning curve each time.

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/2329294.DFZBjWhh24@scott-latitude-e6320

[Scott Kitterman]

That's progress. Of course you still need to know to do git branch -r to see
what the remote branches are named since git branch still won't know about
them. Maybe in another decade it'll be half way usable for people whose life
doesn't revolve around git.

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/4089658.34RS1eJNab@scott-latitude-e6320

[Scott Kitterman]

I've tried doing this. Then I looked back and noticed that I was spending a
LOT of time making the VCS pretty, just in case and rarely had to revert
anything. It turned out I was spending a lot of time to save a little time
and that's just not path to being productive.

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/2844385.4hKU8VhLLv@scott-latitude-e6320

[Scott Kitterman]

On Thursday, February 21, 2013 01:57:11 PM Thomas Goirand wrote:
> On 02/21/2013 12:32 PM, Barry Warsaw wrote:
> > On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:
> >> It is to a degree, but the learning curve for git is subtantially steeper
> >> than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or
> >> another and there is no question in my mind which one, by a lot, is the
> >> most complex to learn.
> >
> > No one's accusing git of actually being user friendly. <wink>
> >
> > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
> >
> > -Barry
>
> Some of the points in this page are really wrong.
> Like in the point 6, 7, 8 and 9, the author didn't understand
> at all the necessity of having fast-forward history when
> a project scales up, with lots of contributors.
>
> Then finally, I agree, the only thing that remains is the
> complexity. :)

If by scales up, you mean the Linux kernel, sure. I agree, but for something
the complexity of DPMT/PAPT where there don't tend to be lots of committers on
the same package, they are valid.

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/1800697.fkr4dhOjoz@scott-latitude-e6320

[Ludovic Gasc]

On Feb 20, 2013 11:57 PM, "Dmitrijs Ledkovs" <xn...@debian.org> wrote:
>
> On 19 February 2013 23:49, Ludovic Gasc <gml...@gmail.com> wrote:
> >
> > On Feb 19, 2013 11:21 PM, "Barry Warsaw" <ba...@python.org> wrote:
> >>
> >> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
> >>
> >
> > I can do that this week-end. I've only a github account to publish the git
> > repository, unless somebody else has an access for a better place? For a
> > test, I think that github is enough.
> >
>
> Using github would be against the basic principles laid out in the
> Debian Social Contract.
> While gitorious hosted solution, would be ok it reimplements the git
> server & protocol and hence lacks many features.
> It is best to continue to use excellent hosting facilities provided by
> git.debian.org / alioth.debian.org.
> One can create repositories in a home directory (please don't use
> official team account / group names) which would be good enough for
> maintainance.

Ok, I'll use it this week-end.

[Thomas Goirand]

On 02/21/2013 01:36 PM, Scott Kitterman wrote:
> Agreed.
>
> I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to
> be able to find it 4 years later).
>
> Scott K

Lucky, 4 years later, the error messages of Git are
much much more helpful than they used to be (in
fact, since version >= 1.7).

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/5125C34B...@debian.org

[Thomas Goirand]

On 02/21/2013 02:29 PM, Scott Kitterman wrote:
> I've tried doing this. Then I looked back and noticed that I was spending a
> LOT of time making the VCS pretty, just in case and rarely had to revert
> anything. It turned out I was spending a lot of time to save a little time
> and that's just not path to being productive.
>
> Scott K

If you are working alone, probably. If you are working
with a team, that's a different story. Having a very
dirty commit history with changes going back and
forth is just horrible and makes it very hard to follow.

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/5125C3E1...@debian.org

[Thomas Goirand]

On 02/21/2013 02:26 PM, Scott Kitterman wrote:
>
>> I undertand that learning Git after BZR is hard, because learning BZR after
>> Git is equally painful. I think that the key difficulty is whether a
>> system is learned first or second, not the system itself.
>>
>> This is where git-buildpackage is nice, as it re-implements the same user
>> experience as with svn-buildpackage, and therefore provides some kind of
>> upgrade path.
> I disagree. Learning git is harder than all the others. It doesn't matter
> what order you learn them in. If you look at the figures in point 10 of
> http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ (you can
> largely substitute bzr for svn there and it won't get any more complex) and
> tell me those are of equal complexity.
>
> For all it's power, the git U/I is just inconsistent and counter intuitive.
> If you use it routinely, you get so you remember it and it seems easy. If you
> don't, you have to re-climb up the learning curve each time.
>
> Scott K

I've learn first CVS. Then switch to Git. Then when I tried to learn bzr,
it was quite hard (and now I can't remember it at all). I always found
SVN something of the past, hard to use and stupid, because I never
took the time to learn it correctly (and in full honesty, I don't think
I should, as there are way better VCS out there). But I perfectly know
this comes *from me* and not the tool itself, which I know shouldn't
be harder to use than CVS, which I used for years.

So I deeply agree with Charles here.

Also, for this point 10, the author completely skipped alltogether
the very reason why Git needs more commands: because it doesn't
do network access all the time. Only when you ask it to do so. And
because I worked with launchpad BZR from China, with about 5 KB/s
of bandwidth to it available (when I could connect at all...), I can tell
you that it is really important. Lucky, launchpad.com has nicer
connectivity now, but that's not what I'm debating. With BZR, I wouldn't
be able to work in the train without my 3G connection opened...

This debate can go on, and on, and on forever. It will go nowhere.
We got the point that you find Git difficult, and like bzr more.
I don't think posting such wrong argumentation helps.

Moreover, ease of use is *not* the main point of any software (it does
seem to me that this is your main point). Sometimes, convenience
means that you do need to learn to later be more efficient.

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/5125C80A...@debian.org

[Omer Zak]

Why not document the workflow (or any other workflow in Debian for that
matter) by means of an executable Makefile with targets like:

help:
egrep ^#DOC Makefile

template:
# Build a script which the user will edit replacing
# keywords by package name etc.
# The script will invoke this Makefile with the right
# values in environmental variables

update:
debcommit -a ...
git buildpackage ...

tag:
git buildpackage --git-tag

import:
# Set the $tarball environment variable
git import-orig $tarball

etc. etc.

--- Omer


--
Make love not war.
More cleavage, less carnage.
My own blog is at http://www.zak.co.il/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.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/1361428448.20304.186.camel@c4

[Piotr Ożarowski]

Can we go back to DPMT/PAPT workflow? Git vs. Bzr vs. Hg war is not
that relevant (and we already know which VCS won, at least in Debian ;P)

Can we focus on what we want (without taking VCS into account if
possible) so that those who will propose workflow/tools/do the initial
migration can start working? I'd love to be forced to choose between
WORKING implementations. I want to play with hg, bzr or git in a
DPMT/PAPT context and THEN decide which works better for me
(I love git, but maybe git-buildpackage is not that shiny as others
describe)
--
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/20130221085...@piotro.eu

[Thomas Goirand]

On 02/21/2013 04:55 PM, Piotr Ożarowski wrote:
> Can we go back to DPMT/PAPT workflow? Git vs. Bzr vs. Hg war is not
> that relevant (and we already know which VCS won, at least in Debian ;P)
>
> Can we focus on what we want (without taking VCS into account if
> possible) so that those who will propose workflow/tools/do the initial
> migration can start working? I'd love to be forced to choose between
> WORKING implementations. I want to play with hg, bzr or git in a
> DPMT/PAPT context and THEN decide which works better for me
> (I love git, but maybe git-buildpackage is not that shiny as others
> describe)

git-buildpackage takes some time to learn.

I think it might be worth trying git-stuff (eg: the package).
I know few people who use it and are happy with it.

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/5125E95C...@debian.org

[Piotr Ożarowski]

[Thomas Goirand, 2013-02-21]

> git-buildpackage takes some time to learn.
>
> I think it might be worth trying git-stuff (eg: the package).
> I know few people who use it and are happy with it.

sure, I will try it. Migrate packages and describe the workflow on wiki
and I will test it.

How about creating wiki page:
http://wiki.debian.org/Teams/PythonModulesTeam/Workflow
and start documenting what we want (once ~agreed here)
then those who wants to change something (and not just talk)
can create for example:
http://wiki.debian.org/Teams/PythonModulesTeam/Wrokflow/GitBuildPackage
or
http://wiki.debian.org/Teams/PythonModulesTeam/Wrokflow/GitStuff
and add a link in /Workflow (in "Proposals" section)

All proposals without wiki pages (and something to play with) will be
rejected and ignored.

--
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/20130221095...@piotro.eu

[Thomas Goirand]

On 02/21/2013 01:59 AM, Scott Kitterman wrote:
> I don't keep local copies of things I don't work on regularly, so for team packages I would be downloading all of it.

I thought about it for a long time. Then I tried again today, and now,
I don't buy into this "it takes too much time to download" argument.

Currently, with SVN, givent the size of the repository, it takes really
a huge amount of time to clone a package *debian folder only*.

>From a server in a data center in Seattle, it took me 90 seconds
to download the packaging sources of python-eventlet. Compare
this to the 4 seconds it takes me to clone python-warlock from
Alioth, upstream source included !!!

Then because this was only a small package with only a very small
amount of upstream code, I tried again to benchmark how much
time it took with a bigger project. Well, with nova, which I consider
a quite big project, it took me 32 seconds to get all of it. And about
10 seconds for glance, which I would consider a medium size project.

Then I repeated the experience from my (very) slow Chinese
ADSL connection. Even there, it took me 42 seconds to clone
glance from Alioth (a 9.4 MB repository).

Scott, I would be *very* surprised if you had an internet connection
slower than mine, considering where you live (if db.debian.org still
has accurate information).

The problem is that with SVN, it takes so much time and space
(as each tag will generate some files), so you might have been
fooled into thinking it would also with Git. But the reality simply
not that at all.

If you could suffer the slowness of SVN for so many years with the
python module team, I'm sure you will like the upgrade to Git which
will make clones so much faster.

So in the end, I don't buy into your point that having an upstream
source branch type of repository is too slow and too big. It's just
simply not the case.

Cheers,

Thomas Goirand

--
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/51271AD6...@debian.org

[Piotr Ożarowski]

[Thomas Goirand, 2013-02-22]

> From a server in a data center in Seattle, it took me 90 seconds
> to download the packaging sources of python-eventlet. Compare
> this to the 4 seconds it takes me to clone python-warlock from
> Alioth, upstream source included !!!

your data is wrong (see below). I don't know what's your goal, but
it certainly isn't doing any real work related to transition.
Please stop.


piotr@hadar /tmp/test
0% time svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/
A trunk/debian
A trunk/debian/control
A trunk/debian/links
A trunk/debian/source
A trunk/debian/source/format
A trunk/debian/python-eventlet.lintian-overrides
A trunk/debian/compat
A trunk/debian/watch
A trunk/debian/changelog
A trunk/debian/patches
A trunk/debian/patches/threading-leak
A trunk/debian/patches/retry-on-timeout
A trunk/debian/patches/series
A trunk/debian/copyright
A trunk/debian/docs
A trunk/debian/rules
A trunk/debian/doc-base
A trunk/debian/examples
Checked out revision 23543.
svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/ 0.05s user 0.01s system 6% cpu 1.025 total
piotr@hadar /tmp/test
0% time debcheckout python-eventlet
declared svn repository at svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/
svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/ python-eventlet ...
A python-eventlet/debian
A python-eventlet/debian/control
A python-eventlet/debian/links
A python-eventlet/debian/source
A python-eventlet/debian/source/format
A python-eventlet/debian/python-eventlet.lintian-overrides
A python-eventlet/debian/compat
A python-eventlet/debian/watch
A python-eventlet/debian/changelog
A python-eventlet/debian/patches
A python-eventlet/debian/patches/threading-leak
A python-eventlet/debian/patches/retry-on-timeout
A python-eventlet/debian/patches/series
A python-eventlet/debian/copyright
A python-eventlet/debian/docs
A python-eventlet/debian/rules
A python-eventlet/debian/doc-base
A python-eventlet/debian/examples
Checked out revision 23543.
repository only contains the debian directory, using apt-get source
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'python-eventlet' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/
Need to get 329 kB of source archives.
Get:1 http://ftp.debian.org/debian/ unstable/main python-eventlet 0.9.16-3 (dsc) [1,559 B]
Get:2 http://ftp.debian.org/debian/ unstable/main python-eventlet 0.9.16-3 (tar) [317 kB]
Get:3 http://ftp.debian.org/debian/ unstable/main python-eventlet 0.9.16-3 (diff) [9,904 B]
Fetched 329 kB in 0s (371 kB/s)
dpkg-source: info: extracting python-eventlet in python-eventlet-0.9.16
dpkg-source: info: unpacking python-eventlet_0.9.16.orig.tar.gz
dpkg-source: info: unpacking python-eventlet_0.9.16-3.debian.tar.gz
dpkg-source: info: applying retry-on-timeout
dpkg-source: info: applying threading-leak
debcheckout python-eventlet
0.80s user 0.09s system 32% cpu 2.696 total

[Nicolas Chauvat]

Hi,

On Wed, Feb 20, 2013 at 11:46:31PM -0500, Barry Warsaw wrote:
> """
> 9. Git history is a bunch of lies
> The primary output of development work should be source code. Is a
> well-maintained history really such an important by-product? Most of the
> arguments for rebase, in particular, rely on aesthetic judgments about “messy
> merges” in the history, or “unreadable logs”. So rebase encourages you to lie
> in order to provide other developers with a “clean”, “uncluttered”
> history. Surely the correct solution is a better log output that can filter
> out these unwanted merges.
> """

http://mercurial.selenic.com/wiki/ChangesetEvolution

"""Changeset Evolution is a set of features to gracefully handle
history rewriting operations. It offers a safe and simple way to
refine changesets. Results of your local history rewriting operations
can be propagated to other clones in a solid way. It is even possible
for multiple people to rewrite the same part of the history in a
distributed way."""

My humble opinion is that this is about to become a major feature of Mercurial.

--
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances

--
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/20130222131...@volans.logilab.fr

[Scott Kitterman]

On Friday, February 22, 2013 03:14:30 PM Thomas Goirand wrote:
...

> The problem is that with SVN, it takes so much time and space
> (as each tag will generate some files), so you might have been
> fooled into thinking it would also with Git. But the reality simply
> not that at all.

...

I almost never check out the entire package, just trunk, so (as Piotr has
indicated) your data is WAY off. This may be where your git experience caused
you to look at this problem suboptimally. One of the real strengths of SVN
over anything newer is the ability to check out just a small part of the
repository without any special preparation for it needed. Developers can get
as much or as little as they need.

I also agree with Piotr that this thread has probably outlived whatever
usefulness it might have had and should stop.

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/4006639.oYv6cMICYi@scott-latitude-e6320

[Thomas Goirand]

On 02/22/2013 03:57 PM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-02-22]
>> From a server in a data center in Seattle, it took me 90 seconds
>> to download the packaging sources of python-eventlet. Compare
>> this to the 4 seconds it takes me to clone python-warlock from
>> Alioth, upstream source included !!!
> your data is wrong (see below).
>

> piotr@hadar /tmp/test
> 0% time svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/

So probably, it's git-svn which is slow (and plain svn isn't). Interesting!

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/51278AFB...@debian.org

[Vincent Bernat]

❦ 22 février 2013 16:12 CET, Thomas Goirand <zi...@debian.org> :

>>> From a server in a data center in Seattle, it took me 90 seconds
>>> to download the packaging sources of python-eventlet. Compare
>>> this to the 4 seconds it takes me to clone python-warlock from
>>> Alioth, upstream source included !!!
>> your data is wrong (see below).
>>
>> piotr@hadar /tmp/test
>> 0% time svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/
> So probably, it's git-svn which is slow (and plain svn
> isn't). Interesting!

git-svn tries to download the whole history. svn don't.
--
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)