Re: output from the vcs-pkg BoF @DebConf9

2009-08-11 Thread James Westby
martin f krafft wrote:
 Canonical wants to make package maintenance uniform. The pragmatic
 approach for them — since vcs-pkg isn't there yet — is to import
 everything in Bazaar. I think we managed to agree that cross-VCS
 support (which is n-factorial) isn't feasible, and so the import
 would have to have an export associated with it. Concretely, rather
 than them importing my mdadm (in Git) repo and expecting me to
 access their Bazaar repo to extract patches, it would make sense for
 Canonical to export commits into a Git repo of their own (presumably
 the one they mirrored from), which is the one I will then use.

Well, format-patch-style patches attached to bug reports would also
allow you to access the changes, so I'm not sure that providing a
git repo is the only way to do it.

 Jelmer's bzr-git adapter could greatly facilitate this.

That's true nevertheless.

Thanks,

James

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-05 Thread David Greaves
martin f krafft wrote:
 1. Add the current set of workflows to our website.
 
It would be great if the currently accepted set of workflows
were to be summarised directly on the webpage, so that we can
officialise them and deprecate all the others floating around.
 
The workflows I know currently are: my topgit workflow, Mehdi's
quilt workflow, and Guido's git-buildpackage approach. There my
be others.

Hi

I've brought mine up for review before - including pretty pictures :
  http://wiki.maemo.org/Mer/Build/UsingGitorious

I'm using this workflow to manage parts (eventually all) of a midstream 'remix'
distro where we have to maintain feature branches for various reasons.

David

-- 
Don't worry, you'll be fine; I saw it work in a cartoon once...

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-05 Thread Guido Günther
On Tue, Aug 04, 2009 at 06:41:10PM +, Frédéric Brière wrote:
 Guido Günther a...@sigxcpu.org wrote:
   Aren't Mehdi and Guido basically doing the same thing?  From what I
   understand, the only difference is that Guido uses git-rebase, while
   Mehdi manually applies the old patches to a new branch (which is exactly
   what git-rebase does).
 
  I think they're pretty similar. I'm just not sure how Mehdi reimports
  the patch series onto the patch-queue branch. I'm doing this as
 
 My understanding is that he deletes the branch, recreates a new one off
 of upstream, and re-populates it from debian/patches.  As I pointed out,
 this is exactly what git-rebase does (apply old patches to a new branch
 point), assuming that patch-queue has not changed since.
The main difference seems to be that my patch-queue branch is based on
the debian branch (i.e. master) while this method uses upstream. Since
in my workflow the debian stuff is confined to debian/ I prefer it this
way since I then have debian/rules, etc. at hand too.

 If you're working solo, I fail to see the advantage; but for
 collaborative work, the fact that it is based on a branch with linear
 history (whether master or your integration branch) instead of
 patch-queue might be of help.
Sure. That's what gbp-pq import is for.
Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-05 Thread Guido Günther
Hi Mehdi,
On Wed, Aug 05, 2009 at 12:02:20AM +0200, Mehdi Dogguy wrote:
[..snip..] 
 I use some scripts :
 
 - Before creating a patch (eventually depending on one already present
 in the patch series), I call dom-apply-patches[1].
 - When I'm done with editing patches, I call dom-save-patches[2].
 
 So, yes I create a fresh branch everytime as Frédéric pointed out. The
 details are in [1] and [2]. It's clearly useless when working solo but
 makes things a bit simpler when working within a team.
 
 [1]
 http://git.debian.org/?p=pkg-ocaml-maint/packages/dh-ocaml.git;a=blob;f=tools/dom-apply-patches;h=1a5e406181d1129047344dbc92544269a6d6378c;hb=HEAD
 [2]
 http://git.debian.org/?p=pkg-ocaml-maint/packages/dh-ocaml.git;a=blob;f=tools/dom-save-patches;hb=HEAD
Looks pretty similar to what I do except that you use upstream while I
use the debian branch as the base. I do that so I can have different
patch-queues for different debian releases like:

patch-queue/master
patch-queue/lenny
patch-queue/bpo-lenny
patch-queue/experimental

The branch point for the patch-queue branch would then always be the tip
of the corresponding debian branch, like:

git branch patch-queue/lenny lenny
git quilt-import debian/patches/series

Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-05 Thread Guido Günther
Hi Stéphane,
On Wed, Aug 05, 2009 at 07:31:13PM +0200, Stéphane Glondu wrote:
 Guido Günther a écrit :
  Looks pretty similar to what I do except that you use upstream while I
  use the debian branch as the base.
 
 This is done on purpose ;-)
thought so ;) this wasn't ment as criticism, i'm just interested in
finding out the reason for the differences to learn from it.

 Actually, my (and Mehdi's) workflow is largely inspired on yours, the
 only thing I changed is basing the patch-queue branch on upstream (and
 not pushing it to the central repository).
 
 I find basing the patch-queue branch on the upstream one more convenient
 because it's much easier to reference the branching point. In this
 regard, basing patch-queue on master doesn't really make sense to me
 and/or leads to too much useless rebasing (at least with the way I work).
You'll have to rebase against the Debian branch if you did changes on it
but that's cheap. Finding the branching point can be done by looking at
the ancestors of the merge commit (if one needs to identify it).

  I do that so I can have different
  patch-queues for different debian releases like:
  
  patch-queue/master
  patch-queue/lenny
  patch-queue/bpo-lenny
  patch-queue/experimental
 
 I don't really see the benefit of keeping patch-queue branches around,
 and I even think they are troublesome. Having each queue serialized in
 its branch's debian/patches is enough, isn't it?
They don't have to be kept around. Whole point is that recreating the
patch-queue branch (for e.g. backports or point releases) works out of
the box. If I understand things correctly in your workflow you'd have to
identify the tag or branch of the old upstream version first and pass
that on to dom-apply-patches? (This could as well be automated of course
by looking at the right tag).

 
  The branch point for the patch-queue branch would then always be the tip
  of the corresponding debian branch, like:
  
  git branch patch-queue/lenny lenny
  git quilt-import debian/patches/series
 
 IMHO, this is really not convenient.
What does the not convenient refer to? 
Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-05 Thread Stéphane Glondu
Guido Günther a écrit :
 [...] Finding the branching point can be done by looking at
 the ancestors of the merge commit (if one needs to identify it).

Sure. But you have to look at your history.

 [...] If I understand things correctly in your workflow you'd have to
 identify the tag or branch of the old upstream version first and pass
 that on to dom-apply-patches? (This could as well be automated of course
 by looking at the right tag).

Right. For branches in the packaging, I create also two branches anyway:
one for debian packaging, and another one for upstream (e.g. sid/master
and sid/upstream), and adapt debian/gbp.conf accordingly in the debian
branch. dom-apply-patches looks at debian/gbp.conf by itself (but
unfortunately, dom-save-patches doesn't work symmetrically... yet, these
scripts are still WIP I guess).

 git branch patch-queue/lenny lenny
 git quilt-import debian/patches/series
 IMHO, this is really not convenient.
 What does the not convenient refer to? 

Basing the patch queue on the debian branch. But maybe it's due to the
way I work: I already do many rebases while working on my local debian
branch and I don't touch upstream sources so much.


Cheers,

-- 
Stéphane


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-04 Thread martin f krafft
also sprach Manoj Srivastava sriva...@acm.org [2009.08.04.1859 +0200]:
  martin f krafft madd...@debconf.org wrote:
 The workflows I know currently are: my topgit workflow, Mehdi's
 quilt workflow, and Guido's git-buildpackage approach. There my
 be others.
 
 I am pretty sure I had sent my own work-flows on -- complete
  with variations and pretty pictures.
 
 But I did not toe the party line on topgit, so I can see why
  they are to be excluded.

Manoj, this oversight was not on purpose. I was doing a million
things at once.

-- 
 .''`.   martin f. krafft madd...@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
i must confess, I was born at a very early age.
   -- groucho marx

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-04 Thread Guido Günther
On Tue, Aug 04, 2009 at 04:37:46PM +, Frédéric Brière wrote:
 martin f krafft madd...@debconf.org wrote:
 The workflows I know currently are: my topgit workflow, Mehdi's
 quilt workflow, and Guido's git-buildpackage approach. There my
 be others.
 
 Aren't Mehdi and Guido basically doing the same thing?  From what I
 understand, the only difference is that Guido uses git-rebase, while
 Mehdi manually applies the old patches to a new branch (which is exactly
 what git-rebase does).
I think they're pretty similar. I'm just not sure how Mehdi reimports
the patch series onto the patch-queue branch. I'm doing this as
described here:

https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-04 Thread Frédéric Brière
Guido Günther a...@sigxcpu.org wrote:
  Aren't Mehdi and Guido basically doing the same thing?  From what I
  understand, the only difference is that Guido uses git-rebase, while
  Mehdi manually applies the old patches to a new branch (which is exactly
  what git-rebase does).

 I think they're pretty similar. I'm just not sure how Mehdi reimports
 the patch series onto the patch-queue branch. I'm doing this as

My understanding is that he deletes the branch, recreates a new one off
of upstream, and re-populates it from debian/patches.  As I pointed out,
this is exactly what git-rebase does (apply old patches to a new branch
point), assuming that patch-queue has not changed since.

If you're working solo, I fail to see the advantage; but for
collaborative work, the fact that it is based on a branch with linear
history (whether master or your integration branch) instead of
patch-queue might be of help.


-- 
 sam /.ing an issue is like asking an infinite number of monkeys for
   advice
-- in #debian-devel


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: output from the vcs-pkg BoF @DebConf9

2009-08-04 Thread Mehdi Dogguy
Guido Günther a écrit :
 On Tue, Aug 04, 2009 at 04:37:46PM +, Frédéric Brière wrote:
 martin f krafft madd...@debconf.org wrote:
The workflows I know currently are: my topgit workflow, Mehdi's
quilt workflow, and Guido's git-buildpackage approach. There my
be others.
 Aren't Mehdi and Guido basically doing the same thing?  From what I
 understand, the only difference is that Guido uses git-rebase, while
 Mehdi manually applies the old patches to a new branch (which is exactly
 what git-rebase does).
 I think they're pretty similar. I'm just not sure how Mehdi reimports
 the patch series onto the patch-queue branch. I'm doing this as
 described here:
 
 https://honk.sigxcpu.org/piki/development/debian_packages_in_git/
 

I use some scripts :

- Before creating a patch (eventually depending on one already present
in the patch series), I call dom-apply-patches[1].
- When I'm done with editing patches, I call dom-save-patches[2].

So, yes I create a fresh branch everytime as Frédéric pointed out. The
details are in [1] and [2]. It's clearly useless when working solo but
makes things a bit simpler when working within a team.

[1]
http://git.debian.org/?p=pkg-ocaml-maint/packages/dh-ocaml.git;a=blob;f=tools/dom-apply-patches;h=1a5e406181d1129047344dbc92544269a6d6378c;hb=HEAD
[2]
http://git.debian.org/?p=pkg-ocaml-maint/packages/dh-ocaml.git;a=blob;f=tools/dom-save-patches;hb=HEAD

Cheers,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss