Re: output from the vcs-pkg BoF @DebConf9

[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

[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

[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

[Stéphane Glondu]

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 ;-)

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

> 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?

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


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

[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

[Guido Günther]

On Tue, Aug 04, 2009 at 06:41:10PM +, Frédéric Brière wrote:
> Guido Günther  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

[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

[Frédéric Brière]

Russ Allbery  wrote:
> http://www.eyrie.org/~eagle/notes/debian/git.html

If I'm not mistaken, this sounds very much like Manoj's workflow:
feature branches that get merged into an integration branch.  Manoj,
would you agree?


-- 
revision 1.17.2.7
date: 2001/05/31 21:32:44;  author: branden;  state: Exp;  lines: +1 -1
AGH!!  GOT THE G** D*** SENSE OF A F*** TEST BACKWARDS!


___
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

[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  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

Re: output from the vcs-pkg BoF @DebConf9

[Russ Allbery]

martin f krafft  writes:

> 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.
>
>At the same time, the website could use some work,
>reorganisation, and cleanup.

My current workflow is at:

http://www.eyrie.org/~eagle/notes/debian/git.html

However, I've been very busy and haven't had a chance to check against
other workflows, so this may largely duplicate what you already have
documented.

http://www.eyrie.org/~eagle/notes/debian/scripts.html

may be interesting as a special-case variation, although it's fairly far
afield from the main purpose of this collection.

-- 
Russ Allbery (r...@stanford.edu) 

___
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

[Manoj Srivastava]

On Tue, Aug 04 2009, martin f krafft wrote:

> also sprach Manoj Srivastava  [2009.08.04.1859 +0200]:
>> > martin f krafft  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.

Well, here are some thoughts on packaging in general:

http://www.golden-gryphon.com/blog/manoj/categories/software/packaging/
  With the pretty picture:
http://www.golden-gryphon.com/blog/manoj/images/git_workflow.png

An analysis of various means of managing features with branches
 is here:
   http://www.golden-gryphon.com/software/misc/packaging.html
(toggle the javascript off to see this as one big page)

I'll be happy to have these hosted on the vcs-pkg web server.

manoj
-- 
If all men were brothers, would you let one marry your sister?
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

___
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

[Frédéric Brière]

Guido Günther  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

[Guido Günther]

On Tue, Aug 04, 2009 at 04:37:46PM +, Frédéric Brière wrote:
> martin f krafft  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

[martin f krafft]

also sprach Manoj Srivastava  [2009.08.04.1859 +0200]:
> > martin f krafft  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   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

[Manoj Srivastava]

On Tue, Aug 04 2009, Frédéric Brière wrote:

> martin f krafft  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
-- 
Disobedience: The silver lining to the cloud of servitude. Ambrose
Bierce
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

___
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

[Frédéric Brière]

martin f krafft  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).

Maybe it's a lack of imagination on my part -- wouldn't be the first
time! -- but I don't see this as N approaches out of many, but merely as
a question of whether you intend to use $(VCS) to develop/maintain
patches, or merely to store them (and take advantage of $(VCS)'s tools).
The former naturally leads to multiple branches and merging; the latter,
to a single branch and rebasing.  From there, what exact steps you take
is a question of details.


-- 
 abuse me.  I'm so lame I sent a bug report to debian-devel-changes
-- Seen on #Debian


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