Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-22 Thread Matthias Klose
Am 22.01.2014 08:28, schrieb Thomas Goirand:
 On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It might
 indeed be so, we're all busy.  But let's hopefully all agree that the end 
 goal
 is to have all team-maintained packages in the same vcs.
 
 I can't answer this question, as I can't speak for the others, and I
 don't have time myself.

sure, so you are proposing something which you don't want to finish, just
pursuing a rather selfish interest of using git yourself.  You did try this with
the debian-java team as well.

 Well, if we decide to move slowly things to Git, then the packages that
 will stay in the SVN repo will be those largely unmaintained...

and these will be magically maintained when converted to Git?  please don't be
silly.  unmaintained packages are not a property of the used VCS. And you said
you don't have time to spend on these yourself.

 http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
 
 The only reason they are maintained within the OpenStack team is because
 I don't want to be forced to use SVN, and I think it's safer than in
 collab-maint where so many people have commit access (which means they
 can rm -rf...).

apparently these were first needed for openstack. so it seems to make sense to
maintain these over there.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dfadf0.9080...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-22 Thread Thomas Goirand
On 01/22/2014 07:39 PM, Matthias Klose wrote:
 Am 22.01.2014 08:28, schrieb Thomas Goirand:
 On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It 
 might
 indeed be so, we're all busy.  But let's hopefully all agree that the end 
 goal
 is to have all team-maintained packages in the same vcs.

 I can't answer this question, as I can't speak for the others, and I
 don't have time myself.
 
 sure, so you are proposing something which you don't want to finish, just
 pursuing a rather selfish interest of using git yourself.  You did try this 
 with
 the debian-java team as well.

I don't think so. I don't maintain any Java package.

 Well, if we decide to move slowly things to Git, then the packages that
 will stay in the SVN repo will be those largely unmaintained...
 
 and these will be magically maintained when converted to Git?

I guess, not more than with SVN...

 please don't be silly.

I don't think I have. You are making wrong assumptions here, I believe.

 unmaintained packages are not a property of the used VCS.

Agreed!!!

 And you said
 you don't have time to spend on these yourself.
 
 http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

 The only reason they are maintained within the OpenStack team is because
 I don't want to be forced to use SVN, and I think it's safer than in
 collab-maint where so many people have commit access (which means they
 can rm -rf...).
 
 apparently these were first needed for openstack. so it seems to make sense to
 maintain these over there.

That's truth only for a subset of them, not all of them. Many are of
general purpose.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dfca83.7020...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Dimitri John Ledkov
On 15 January 2014 02:29, Chow Loong Jin hyper...@debian.org wrote:
 On Tue, Jan 14, 2014 at 04:51:20PM +0100, Olivier Berger wrote:
 Now, if you both want to track upstream sources from origin/master on
 local upstream/ branch and svn's trunk on local master branch, then,
 yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges
 now and then.

 git import-orig --filter=debian helps to avoid nasty merges, as long as you
 don't make changes to the upstream sources directly inside your packaging 
 branch
 -- there shall be no conflicts if upstream does not touch debian and you do 
 not
 touch the upstream sources.

 gbp-pq is also wonderful for maintaining quilt patch series.

My preference lately is strongly with: dgit + git-dpm (for patch management).

git-dpm does not polute repository with branches of any sort, it
simply maintains a round-trip-safe conversion from debian/patches to a
branch and back again.
(Something very similar to Mercurial Queues but done nicer and more
specific to debian packaging)

I haven't yet found a way to use dgit/git-dpm against svn repository.
I'm thinking to simply do dsc-import on the svn side, after I generate
an upload with dgit/git-dpm.
Once the kinks are worked out, and some sort of forest (mr or repo)
management is in place we can start opening up an outstanding git
powered workflow.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhlugki6ptvmhd6qihm80hhgr0mbgypc2aa+cvpmjr9gp...@mail.gmail.com



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Thomas Goirand
On 01/14/2014 09:24 PM, Alexandre Rossi wrote:
 I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).

Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable, predicted, and unavoidable.

In fact, using collab-maint is something that I would advise right now
if nothing moves in this team.

On 01/14/2014 09:55 PM, Piotr Ożarowski wrote:
 I reported bug reports, thanks

Why doing this? It doesn't make sense. It seems obvious to me that the
person using collab-maint do want to use Git. Don't force them back to
SVN please, it wouldn't be nice to them, especially if our plan is to
migrate away from it at some point. I don't see this as a bug, I see it
as a problem in the Python team, unless the Git repo is reactivated, and
the person who deactivated it doesn't do it again.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 I need to spend more time playing with git-bp, but last time I looked at it
 (cannot remember which package), I had a lot of trouble unless the package
 repo was organized Just Right.  One nice thing about svn-bp is that it pretty
 much just works with a checked out working directory, even when you have local
 uncommitted changes (--svn-ignore-new).

Probably you're not used enough with Git, because for what I'm doing,
it pretty much just work with a checked out working directory with Git
as well.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 git-bp OTOH required a specific set of branches inside the repo to
 stitch everything together and if those were missing, it failed
 miserably.

It all depends how you do it. If you base your Git packaging on tags,
and not using branches, which means having a debian/gbp.conf that
configures this, then it's really strait forward.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 I've mostly made my peace with git, so in theory I wouldn't be
 opposed to the team switching

There's been a vote that we should switch already. I don't think it's a
good idea to express oneself about liking or not Git: we agreed we
should switch to it.

, but I still think it's not a good idea
 to have some team packages in git and the bulk in svn.  I value the
 ability to use the same tools and workflows for all team maintained
 packages.

Now, this could be back on the table: it's been months that we've talked
about it, and nothing is happening, because nobody has time. So the only
way I see to switch is to do it slowly, having both SVN and Git for some
time. Other teams have reported that it worked for them, so I don't see
why it wouldn't for python modules.

By the way, something like mr (from Joey Hess) could help regarding
mass commits.

On 01/14/2014 11:09 PM, Hans-Christoph Steiner wrote:
 I'm a fan of a gradual transition like this, with people switching or
 setting up git repos as they can.

I'm not a fan of it (it'd be IMO better to completely switch), but I
don't see any other practical way to move forward right now.

On 01/14/2014 11:51 PM, Olivier Berger wrote:
 It more or less requires only 2 branches : upstream (when you
 want to track upstream sources) and master (or debian) for the
 packaging source.

Hum... I'd say that *your workflow* requires it, but git-buildpackage
itself doesn't. You don't have to do this way. Everything can be
contained in a single branch if you use tags. Also, if you don't use
tags, and prefer to use upstream tarballs, then I think you're much
better off using pristine tar (and git-import-orig).

Also, I don't like using debian and master for branch names. These
express nothing. It's much better to use unstable-debian and
upstream-debian for example.

As a reference, here's a debian/gbp.conf for tags:
[DEFAULT]
debian-branch = debian/unstable
upstream-tag = %(version)s

And here's one for pristine-tar:
[DEFAULT]
upstream-branch = upstream-unstable
debian-branch = debian-unstable
pristine-tar = True

I also always add in my debian/gbp.conf:
[git-buildpackage]
export-dir = ../build-area/

to make sure no contributors dirties the git with build files (yes, you
can do that in your ~/.gbp.conf, and the system configuration file in
/etc, but the point here is to make sure *everyone* uses the build-area).

Thomas

[1] I know who it is, though I don't think it is useful to tell who.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df4045.6080...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Steve Langasek
On Wed, Jan 22, 2014 at 11:51:33AM +0800, Thomas Goirand wrote:
 On 01/14/2014 10:31 PM, Barry Warsaw wrote:
  I need to spend more time playing with git-bp, but last time I looked at it
  (cannot remember which package), I had a lot of trouble unless the package
  repo was organized Just Right.  One nice thing about svn-bp is that it 
  pretty
  much just works with a checked out working directory, even when you have 
  local
  uncommitted changes (--svn-ignore-new).

 Probably you're not used enough with Git, because for what I'm doing,
 it pretty much just work with a checked out working directory with Git
 as well.

git-buildpackage has a few misbehaviors by default: the fact that it builds
in place by default instead of exporting to a separate dir is annoying
(--git-export-dir=../build-area/), and that you have to pass it extra
options when you're building from a branch named 'debian'
(--git-debian-branch=branch_name).  IIRC there are subtle differences in
behavior between --svn-ignore-new and --git-ignore-new, but I don't remember
now what they are.

Its pristine-tar handling is pretty solid, though.

 On 01/14/2014 10:31 PM, Barry Warsaw wrote:
  git-bp OTOH required a specific set of branches inside the repo to
  stitch everything together and if those were missing, it failed
  miserably.

 It all depends how you do it. If you base your Git packaging on tags,
 and not using branches, which means having a debian/gbp.conf that
 configures this, then it's really strait forward.

Yes, having to edit debian/gbp.conf on a per-branch basis to even get the
package to build is an annoying misfeature.

 Also, I don't like using debian and master for branch names. These
 express nothing. It's much better to use unstable-debian and
 upstream-debian for example.

 As a reference, here's a debian/gbp.conf for tags:
 [DEFAULT]
 debian-branch = debian/unstable
 upstream-tag = %(version)s

 And here's one for pristine-tar:
 [DEFAULT]
 upstream-branch = upstream-unstable
 debian-branch = debian-unstable
 pristine-tar = True

 I also always add in my debian/gbp.conf:
 [git-buildpackage]
 export-dir = ../build-area/

 to make sure no contributors dirties the git with build files (yes, you
 can do that in your ~/.gbp.conf, and the system configuration file in
 /etc, but the point here is to make sure *everyone* uses the build-area).

Right... these are things the end user (or the package maintainer) should
not have to configure :)

But I don't think the DPMT should wait for these buglets to be fixed in
git-buildpackage before switching to git.  (Not that my opinion matters
anyway. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Barry Warsaw
On Jan 21, 2014, at 08:05 PM, Steve Langasek wrote:

git-buildpackage has a few misbehaviors by default: the fact that it builds
in place by default instead of exporting to a separate dir is annoying
(--git-export-dir=../build-area/), and that you have to pass it extra
options when you're building from a branch named 'debian'
(--git-debian-branch=branch_name).  IIRC there are subtle differences in
behavior between --svn-ignore-new and --git-ignore-new, but I don't remember
now what they are.

That's my vague recollection too.

Right... these are things the end user (or the package maintainer) should
not have to configure :)

But I don't think the DPMT should wait for these buglets to be fixed in
git-buildpackage before switching to git.  (Not that my opinion matters
anyway. :)

Agreed.  We have precedence here too: there were annoying buglets in the
Python helpers, which we documented around until they were fixed[*].  We can
do the same thing here too, because wikis.

Cheers,
-Barry

[*] like having to explicitly loop through Python versions until pybuild came
along. :)


signature.asc
Description: PGP signature


Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Thomas Goirand
On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It might
 indeed be so, we're all busy.  But let's hopefully all agree that the end goal
 is to have all team-maintained packages in the same vcs.

I can't answer this question, as I can't speak for the others, and I
don't have time myself.

 So let's say we have to move packages slowly.  I want to make sure there's a
 team commitment (and especially from the git proponents) that we'll have a
 deadline at which all remaining packages will be switched.  I *really* want to
 avoid the typical long tail where packages just linger under svn and bit rot.
 (E.g. long tail conversions to dh_python2.)

Well, if we decide to move slowly things to Git, then the packages that
will stay in the SVN repo will be those largely unmaintained...

 So I would be in favor of an experiment. Pick 5 packages that are
 representative of team packages, that can be updated and uploaded by anyone on
 the team, and that see regular but not too often new upstream releases.  I'd
 happily volunteer one of my packages if that helps.

Well, if the team decides to move to Git, then I would put *ALL* of the
python module packages I maintain for OpenStack directly within the
DPMT. That's a consequent list of about 50 python modules:

http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

The only reason they are maintained within the OpenStack team is because
I don't want to be forced to use SVN, and I think it's safer than in
collab-maint where so many people have commit access (which means they
can rm -rf...).

 The most important thing though is to *document* in detail *on the wiki* how
 to work with those packages in git.

I agree that documenting the workflow is very important. I have
described my workflow here for OpenStack:
http://openstack.alioth.debian.org/

I wish to continue using this git based workflow whenever possible, and
use the pristine-tar workflow when there's no upstream git.

 Be opinionated, like the way we are with
 the LibraryStyleGuide.  Don't worry if others disagree with you - we can hash
 out best practices in this mailing list over time, but it's really important
 to put a stake in the ground.  If you can't decide which of two ways is
 better, do one package one way and another the other way.

I do believe in freedom as well! :)

 On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote:
 Yes, because someone found it useful to disable the git area in the team
 repo on Alioth [1] !!! And this drove people to collab-maint. This was
 predictable, predicted, and unavoidable.
 
 I don't know if my proposed experiment means re-enabling git on the team repo

I believe it does.

 or doing the experiment on collab-maint.

Any non-DD will have to request for access to collab-maint. This is
unnecessary, potentially dangerous, and administratively heavy to do that.

 But then my question is: how closely does your vision of the team git repo
 overlap with general Debian initiatives like dgit and source branches?  It
 might be nice if they align rather closely.

I don't think this is related. I see dgit as a tool to use only if the
package isn't maintained using Git...

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df7328.8040...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Barry Warsaw
On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:

I've used git-buildpackage with git-svn on submodules of the DPMT SVN
repo without too many difficulties so far.

I need to spend more time playing with git-bp, but last time I looked at it
(cannot remember which package), I had a lot of trouble unless the package
repo was organized Just Right.  One nice thing about svn-bp is that it pretty
much just works with a checked out working directory, even when you have local
uncommitted changes (--svn-ignore-new).

git-bp OTOH required a specific set of branches inside the repo to stitch
everything together and if those were missing, it failed miserably.  I could
be totally wrong about that, or I could have just been using the tool
incorrectly.

I've mostly made my peace with git, so in theory I wouldn't be opposed to the
team switching, but I still think it's not a good idea to have some team
packages in git and the bulk in svn.  I value the ability to use the same
tools and workflows for all team maintained packages.

I'm not motivated enough to do any work on such a transition itself, so I
think those who really want to switch to git need to work out a plan.  That
would include test repos, documentation updates, transition plans, educating
team members, fielding questions, fixing problems, etc.  I would personally be
supportive, and would be willing to review material and test out recipes.  But
I think this is going to require a few committed people to do some heavily
lifting over an extended period of time to make sure such a transition was
smooth and so that everyone on this team was comfortable with the new way of
doing things.

That's just my opinion, of course.
-Barry


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114093100.3da46...@anarchist.wooz.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Hans-Christoph Steiner


On 01/14/2014 09:31 AM, Barry Warsaw wrote:
 On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:
 
 I've used git-buildpackage with git-svn on submodules of the DPMT SVN
 repo without too many difficulties so far.
 
 I need to spend more time playing with git-bp, but last time I looked at it
 (cannot remember which package), I had a lot of trouble unless the package
 repo was organized Just Right.  One nice thing about svn-bp is that it pretty
 much just works with a checked out working directory, even when you have local
 uncommitted changes (--svn-ignore-new).
 
 git-bp OTOH required a specific set of branches inside the repo to stitch
 everything together and if those were missing, it failed miserably.  I could
 be totally wrong about that, or I could have just been using the tool
 incorrectly.
 
 I've mostly made my peace with git, so in theory I wouldn't be opposed to the
 team switching, but I still think it's not a good idea to have some team
 packages in git and the bulk in svn.  I value the ability to use the same
 tools and workflows for all team maintained packages.
 
 I'm not motivated enough to do any work on such a transition itself, so I
 think those who really want to switch to git need to work out a plan.  That
 would include test repos, documentation updates, transition plans, educating
 team members, fielding questions, fixing problems, etc.  I would personally be
 supportive, and would be willing to review material and test out recipes.  But
 I think this is going to require a few committed people to do some heavily
 lifting over an extended period of time to make sure such a transition was
 smooth and so that everyone on this team was comfortable with the new way of
 doing things.
 
 That's just my opinion, of course.
 -Barry

I know what you mean about it having a brittle setup, but git-buildpackage has
improved a lot over the past couple of years.  One key thing that helps when
using git-buildpackage in a team setting (pkg-multimedia is a good example) is
having a standard debian/gbp.conf that configures everything in a standard way
for that team.

For example, it would be great to include a debian/gbp.conf that sets up the
git-svn stuff and check that into svn projects.  Then people can easily use
git-buildpackage and still commit to svn repos.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d55426.6030...@at.or.at



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Olivier Berger
Barry Warsaw ba...@debian.org writes:

 On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:

I've used git-buildpackage with git-svn on submodules of the DPMT SVN
repo without too many difficulties so far.

 git-bp OTOH required a specific set of branches inside the repo to stitch
 everything together and if those were missing, it failed miserably.  I could
 be totally wrong about that, or I could have just been using the tool
 incorrectly.


It more or less requires only 2 branches : upstream (when you
want to track upstream sources) and master (or debian) for the packaging
source.

But for repos of DPMT which won't track upstream code in the SVN, you
only need to manage the debian/ subdir on the master branch which
correspons to the trunk, so that means that git svn clone --std-layout
basically sets things up for you.

Now, if you both want to track upstream sources from origin/master on
local upstream/ branch and svn's trunk on local master branch, then,
yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges
now and then.

In any case, reading
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html
more or less covers all the cases I've played with so far, AFAICT.

YMMV ;-)

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877ga2v9xj@inf-8660.int-evry.fr