Re: How to cope with patches sanely

[David Nusinow]

On Mon, Feb 25, 2008 at 03:56:49AM -0600, Manoj Srivastava wrote:
> No, it does not. If branch A has
>  pi = 2.34567;
>and branch B has
>  pi = 3.14159;
> 
> No matter how much quilting you do you cannot reconcile the
>  fundamental conflict in the final. Either pi is 3.14159; or it is not;
>  and if branch A requires pi not to be that value, and branch B requires
>  pi to be that value, quilt can't make C be quantum like and have the
>  value be both.

Feature branches don't magically allow you to avoid merge conflicts either,
so this is a red herring. Once you've resolved the conflict, then it
becomes just another change. This change can become a diff in a stack of
diffs.

 - David Nusinow
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Pierre Habouzit]

On Mon, Feb 25, 2008 at 04:06:31PM +, Cyril Brulebois wrote:
> On 25/02/2008, Pierre Habouzit wrote:
> >   I'm planning to write a textual version of what I demonstrated at
> > FOSDEM, with some more ideas that I had talking with Julien Cristau
> > on the grass after.
> 
> Please, pretty please, include graphics. Be it ASCII art-like
> drawings, or gitk screenshots, with some additional arrows and other
> comments. Not that I need it, but that would (have been|be) nice.

  That's exactly the plan.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp5WMFv1qg5J.pgp
Description: PGP signature
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Cyril Brulebois]

On 25/02/2008, Pierre Habouzit wrote:
>   I'm planning to write a textual version of what I demonstrated at
> FOSDEM, with some more ideas that I had talking with Julien Cristau
> on the grass after.

Please, pretty please, include graphics. Be it ASCII art-like
drawings, or gitk screenshots, with some additional arrows and other
comments. Not that I need it, but that would (have been|be) nice.

Cheers,

-- 
Cyril Brulebois


pgpmCHGmmuFSF.pgp
Description: PGP signature
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Mon, 25 Feb 2008 10:33:48 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said: 

> On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote:
>> On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said:
>> 
>> > On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
>> >> David Nusinow <[EMAIL PROTECTED]> writes:
>> >> 
>> >> > The problem is that you and Manoj assume that this is the only
>> >> > way to do things. I don't believe this. Pierre Habouzit has been
>> >> > experimenting with an alternative method of feature branches
>> >> > that exports to a linear stack of diffs just fine. Just because
>> >> > Manoj is doing something one way right now doesn't mean it's the
>> >> > only or even the correct way to do it.
>> 
>> I would be interested in details of this, and whether this approach
>> works with pure feature branches where the features are being
>> developed contemporaneously with each other an upstream development;
>> and thus the branches overlap both temporally and in code space.

>   I'm planning to write a textual version of what I demonstrated at
> FOSDEM, with some more ideas that I had talking with Julien Cristau on
> the grass after.

>   You developped them contemporaneously, okay, but in the end you
> merge them one after the other.

No, I do not. I developed feature A a bit, merged that. Then I
 developed feature B a bit, and merged that. Then I developed feature A
 some more. The there came an upstream version. Then feature B ...

> If you're doing criss-cross merges, well, I can nothing for you, and
> you're creating really messy histories, and yes, you need an SCM to
> represent that in a satisfying way.

Thanks. So most of my packages will not get any help from the
 tool you are talking about -- and thus, it can't be made into a policy
 requirement.

> But if you really merge one feature branch on top of the other, and
> it's in my experience *way enough* for what we need in Debian
> packaging, then multiple branches are just multiple series to be
> applied in a specific relative order.

But that is not how development happens in long running sets of
 features, which have been under development, incrementally, over a
 large number of upstream versions.


>   When it comes to specific patches of yours, I really believe that
> topic branches like you advertise them are the best answer. Git makes
> merging easy (s/Git/reasonnable $DSCM/ for this matter btw) in the
> sense that merging is fast enough, and easy enough when the branches
> you merge have not diverged too much. I mean, no matter which SCM you
> use, merging from a branch that is _very_ old, and still not merged
> upstream is jut a pain.

Depends. I keep the topic branches updated with each upstream
 release, and I have carried fvwm/make/flex patches around for years and
 several upstream upgrades, and not had much problems.  Indeed, most
 upstream upgrades have taken _no_ manual effort.

> And it's again not an SCM issue. A patch queue _is_ a branch in
> itself. Really. There are two ways to look at that. Either you say, I
> always want to remember I started from this point, and then you merge
> and merge and merge, and your history looks like that:

> R are uptream releases, M your repeated merges to keep the feature
> branch current.

> -o---o---o--[...]--R--[...]--R--[...]--o--
>   \ \ \
>p--p--p--p---M-M...[feature branch]

Right.

> Well with this approach, upstream will have to take a messy history
> with a _lot_ of merge points they don't care about, and won't be able
> to try your feature branch on top of their current work and maybe
> eventually adopt it. And worse, if you have to add new patches along
> the way, you get an history with a mixed suite of patches and merges,
> which is unreadable to upstream.

Heh. Most of my upstream are fed just a patch, since lots of
 them are using CVS.

In Git terms, I always rebase my patch on each upstream version,
 and can then feed a nice, coherent, minimal patch with no real complex
 history.

> The other way is to forget about giving depth *in* the SCM to the
> patches history. Because it's what it's about. What you really want
> IMSHO is: I have this patch queue [pq] and at upstream R0 it was in
> state pq0, in upstream R1 it was in state pq1 and so on. Without any
> useless merge points in it. This way your feature branch is a free (as
> in only attached to history by its base) branch that you rewrite for
> each new upstream, serialize under debian/patches/. In
> git, there is this awesome git-quiltimport command that allow you to
> rebuild a branch from a quilt series in a trivial way. If you want to
> work on the patch queue, you just need to make it a branch again, do
> your stuff, serialize it again, and you're done.

Err, I see little benefit in doing that; and I think that I
 prefer my current  feature branch mechanism as being less hassle. I
 peri

Re: How to cope with patches sanely

[Manoj Srivastava]

On Mon, 25 Feb 2008 09:35:13 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.25.0828
> +0100]:
>> I am not opposed to it. If you can somehow magically create a tool
>> that can linearize the feature branches, more power to you. I
>> personally find the prospect highly unlikely; and I would like to see
>> some code, please, before I grant that such a thing is possible.

> The tool I envision would simply surf through the history of the
> integration branch and identify merge commits. Each merge would become
> a patch in the quilt series.

How are you planning on doing this identification? Looking at
 the arch logs, it is not trivial to identify merge commits and the
 upgrade patches (which are just merges from the upstream branch),
 unless you start with an ancient version (like, from my 2003 repo) and
 then apply every single commit to the integration branch over the last
 five years (with really really huge numbers of patches).

You'll have to track repo changes, figure out how to overcome
 sealed branch boundaries, etc.

I am not sure I believe this to be feasible until I see some
 code. 

>> Sure. You can't integrate two features that fundamentally conflict
>> with each other. No amount of smoke and mirrors can obscure that
>> fundamental obstacle. This is independent of the tool set you use.

> Except that quilt provides the necessary glue to handle it, while
> feature branches don't.

No, it does not. If branch A has
 pi = 2.34567;
   and branch B has
 pi = 3.14159;

No matter how much quilting you do you cannot reconcile the
 fundamental conflict in the final. Either pi is 3.14159; or it is not;
 and if branch A requires pi not to be that value, and branch B requires
 pi to be that value, quilt can't make C be quantum like and have the
 value be both.

manoj
-- 
Griffin's Thought: When you starve with a tiger, the tiger starves last.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Pierre Habouzit]

On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote:
> On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow <[EMAIL PROTECTED]> said: 
> 
> > On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
> >> David Nusinow <[EMAIL PROTECTED]> writes:
> >> 
> >> > The problem is that you and Manoj assume that this is the only way
> >> > to do things. I don't believe this. Pierre Habouzit has been
> >> > experimenting with an alternative method of feature branches that
> >> > exports to a linear stack of diffs just fine. Just because Manoj is
> >> > doing something one way right now doesn't mean it's the only or
> >> > even the correct way to do it.
> 
> I would be interested in details of this, and whether this
>  approach works with pure feature branches where the features are being
>  developed contemporaneously with each other an upstream development;
>  and thus the branches overlap both temporally and in code space.

  I'm planning to write a textual version of what I demonstrated at
FOSDEM, with some more ideas that I had talking with Julien Cristau on
the grass after.

  You developped them contemporaneously, okay, but in the end you merge
them one after the other. If you're doing criss-cross merges, well, I
can nothing for you, and you're creating really messy histories, and
yes, you need an SCM to represent that in a satisfying way.

  But if you really merge one feature branch on top of the other, and
it's in my experience *way enough* for what we need in Debian packaging,
then multiple branches are just multiple series to be applied in a
specific relative order.

  The problem is, I believe that there are two kind of things: patches
that you backport from upstream. If you're lucky enough to have an
upstream using git, it's just a matter of merging the stable branch into
yours, or cherry-picking some patches, which will not create conflicts
when you merge back. This goes in the .diff.gz, and it's okay (at least
I think so) because it's patches that _everyone_ can take from upstream
as well. You don't need to make them special, and it's always possible
to generate some kind of flat file to say, okay, I cherry-picked this
patch this patch and this patch from upstream, or merged up to this
point of this upstream branch. This information is more useful than the
patch series for derived distros, or co-maints.

  When it comes to specific patches of yours, I really believe that
topic branches like you advertise them are the best answer. Git makes
merging easy (s/Git/reasonnable $DSCM/ for this matter btw) in the sense
that merging is fast enough, and easy enough when the branches you merge
have not diverged too much. I mean, no matter which SCM you use, merging
from a branch that is _very_ old, and still not merged upstream is jut a
pain. And it's again not an SCM issue. A patch queue _is_ a branch in
itself. Really. There are two ways to look at that. Either you say, I
always want to remember I started from this point, and then you merge
and merge and merge, and your history looks like that:

R are uptream releases, M your repeated merges to keep the feature
branch current.

-o---o---o--[...]--R--[...]--R--[...]--o--
  \\ \
   p--p--p--p---M-M...[feature branch]

  Well with this approach, upstream will have to take a messy history
with a _lot_ of merge points they don't care about, and won't be able to
try your feature branch on top of their current work and maybe
eventually adopt it. And worse, if you have to add new patches along the
way, you get an history with a mixed suite of patches and merges, which
is unreadable to upstream.

  The other way is to forget about giving depth *in* the SCM to the
patches history. Because it's what it's about. What you really want
IMSHO is: I have this patch queue [pq] and at upstream R0 it was in
state pq0, in upstream R1 it was in state pq1 and so on. Without any
useless merge points in it. This way your feature branch is a free (as
in only attached to history by its base) branch that you rewrite for
each new upstream, serialize under debian/patches/. In
git, there is this awesome git-quiltimport command that allow you to
rebuild a branch from a quilt series in a trivial way. If you want to
work on the patch queue, you just need to make it a branch again, do
your stuff, serialize it again, and you're done.

  While doing that, your workflow allow people to do meaningful changes
to your package (by adding patches to a given queue), that you'll
transparently *painlessly* import into your workflow. Whereas with your
current one, you'll have to extract whatever the NMUer did that is a
flat debdiff, and split it. It's horrible for you, don't please pretend
otherwise, I won't believe you. The other gain, is that upstream can
look at a current, unencumbered patch queue about the feature you added,
and can take a decent decision about the fact that it's good to take
upstream or not, and it's trivial to export such

Re: How to cope with patches sanely

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.25.0828 +0100]:
> I am not opposed to it. If you can somehow magically create a
>  tool that can linearize the feature branches, more power to you. I
>  personally find the prospect highly unlikely; and I would like to see
>  some code, please, before I grant that such a thing is possible.

The tool I envision would simply surf through the history of the
integration branch and identify merge commits. Each merge would
become a patch in the quilt series.

> Sure. You can't integrate two features that fundamentally
>  conflict with each other. No amount of smoke and mirrors can obscure
>  that fundamental obstacle. This is independent of the tool set you
>  use. 

Except that quilt provides the necessary glue to handle it, while
feature branches don't.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
echo '[dO%O+38%O+PO/d0<0]Fi22os0CC4BA64E418CE7l0xAP' | dc


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Raphael Hertzog]

Hi,

On Sun, 24 Feb 2008, Manoj Srivastava wrote:
> I like the reduced work for each upload, and since it satisfies
>  the use cases of being able to present upstream with a pure feature
>  changeset;

It doesn't satisfy it completely. You can always generate a patch for
a pure feature changeset but you can't guarantee that all those feature
patches apply at the same time.

Let's say you have 5 feature patches, the upstream maintainer wants to
integrate 3 of them. How can you submit 3 patches that would apply one
after the other? You have to redo some of your integration work that you
already did.

That said, even with a pure quilt set of patches, you can't guarantee it
either. If one of the wanted patch has some overlap with one of the
non-wanted ones...

All in all, I think we do all exagerate the problems. In my experience,
most of the patches applied to a Debian package are relatively independant
of each other and inter-relationships is the exception, not the rule.

But if we can come up with a solution that handles perfectly
inter-dependant patches, that would still be great. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627
> +0100]:
>> I am not sure you have understood feature branches.  They are
>> independent, no matter what the overlap. Each feature branch tracks
>> one feature against upstream, no matter how the other features work.
>> 
>> The overlap management is done in the integration branch. This is
>> significantly different from a quilt series, as others have already
>> mentioned in this thread,which is a dependent series of linearized
>> patches; and a change in an earlier feature impacts all subsequent
>> patches (and quilt is good at automating the handling of that
>> impact). [[duplicated so this can be archived on the vcs-package
>> mailing list as well]]

> well, I know what feature branches are but I suppose I jumped the
> gun. They are independent until you integrate them. But you will
> integrate them, thus I tend to think of them as interdependent from
> the start.

You have a strange definition of interdependent.  The majority
 of my feature branches are really orthogonal;  seldom on integration
 there is no conflict; so it is hard for me to think of them as somehow
 inter dependent. Sure, there are overlapping changes, sometimes, but
 these are mostly one time resolution issues.

> Anyway, we're not talking about developing with quilt. We are talking
> about converting feature branches to quilt patches for the sake of
> representation in the source package. I don't see why you would oppose
> to that at all, to be honest.

I am not opposed to it. If you can somehow magically create a
 tool that can linearize the feature branches, more power to you. I
 personally find the prospect highly unlikely; and I would like to see
 some code, please, before I grant that such a thing is possible.

>> Or the patch manager does integration. *Shrug*.  Someone has to do
>> integration sometime.  That is the nature of the beast.  The trick is
>> to do it once, and never have to think about it again.

> ... except when one feature needs to change and then conflicts with
> another feature on re-integration.

Sure. You can't integrate two features that fundamentally
 conflict with each other. No amount of smoke and mirrors can obscure
 that fundamental obstacle. This is independent of the tool set you
 use. 

>> B) Development happens on the feature branch.
> [...]
>> 2) Development on one of the branches conflicts with one or more
>> other features. Here, the human has to figure out the difference on
>> the integration branch -- once.

> No, every time you do development on the branch. And every time, you
> have to remember which branch dependended/conflicted on the feature
> branch you're currently working on, or figure it out by trial and
> error. I don't consider this efficient. This is work that a computer
> should be doing.

Strange. In all my years of using feature branches, I have never
 had to consider which branch depended on what. So no, I don't think I
 _have_ to remember any  such thing; trust me, I would have noticed.  I
 have 30+ packages, and have been using feature branches since  early
 this decade.

If you have a whole slew of features that depend on other
 features, then your feature set is very different from ones I have
 encountered. Dependent features do require more work; but not as much,
 in my opinion, as using quilt or dpatch; but your mileage may vary.

For the most part, I just develop on each branch independently.
 I compile, test, hack, compile, on each individual featre branch. And
 never ever worry about what the other feature branches are like, while
 doing so.

Once in a blue moon (more or less) I have to deconflict the
 integration branch; but mostly those are swiftly resolved issues. And
 once resoved, I tend to forget about them too.  All this worrying about
 branch conflicts seem to be more the realm of quilt and other patch
 series mechanisms; which is mostly my reason to dislike them.

manoj
-- 
(It is an old Debian tradition to leave at least twice a year ...) Sven
Rudolph
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627 +0100]:
> I am not sure you have understood feature branches.  They are
>  independent, no matter what the overlap. Each feature branch tracks one
>  feature against upstream, no matter how the other features work.
> 
> The overlap management is done in the integration branch. This
>  is significantly different from a quilt series, as others have already
>  mentioned in this thread,which is a dependent series of
>  linearized patches; and a change in an earlier feature impacts all
>  subsequent patches (and  quilt is good at automating the handling of
>  that impact). [[duplicated so this can be archived on the vcs-package
>  mailing list as well]]

well, I know what feature branches are but I suppose I jumped the
gun. They are independent until you integrate them. But you will
integrate them, thus I tend to think of them as interdependent from
the start.

Anyway, we're not talking about developing with quilt. We are
talking about converting feature branches to quilt patches for the
sake of representation in the source package. I don't see why you
would oppose to that at all, to be honest.

> Or the patch manager does integration. *Shrug*.  Someone has to
>  do integration sometime.  That is the nature of the beast.  The trick is
>  to do it once, and never have to think about it again.

... except when one feature needs to change and then conflicts with
another feature on re-integration.

>  B) Development happens on the feature branch.
[...]
> 2) Development on one of the branches conflicts with one or more
>other features. Here, the human has to figure out the difference
>on the integration branch -- once.

No, every time you do development on the branch. And every time, you
have to remember which branch dependended/conflicted on the feature
branch you're currently working on, or figure it out by trial and
error. I don't consider this efficient. This is work that a computer
should be doing.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
windoze 98:  useless extension to a minor patch release for 32-bit
  extensions and a graphical shell for a 16-bit patch to an 8-bit
  operating system originally coded for a 4-bit microprocessor, written
  by a 2-bit company that can't stand for 1 bit of competition.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

Hi,

I think one of the differences that patch series mechanism has
 wrt to new development, either in a feature or upstream, is that it
 requires updates to the integration work doe every single upload. It
 also requires a strict ordering between each feature, making it harder
 to compile and test each feature independently.  It is nice that quilt
 helps keep the integration patch up to date; but this is extra work I
 am glad not to have to do.

An integration branch does the integration once, and does not
 bother to explicitly keep the integration patch updated for every
 upload -- but it does keep each feature branch  up to date, and the
 integration branch has a current set of features. This is reduced work
 load for each change; at the expense of stashing integration knowledge
 deep in the entrails of the integration branch.

I like the reduced work for each upload, and since it satisfies
 the use cases of being able to present upstream with a pure feature
 changeset; to be able to rapidly compare any feature branch against
 each other or upstream, and being able to maintain an integrated source
 tree for Debian packages, I am happy not to keep integration patches up
 to date.

Now, if there is indeed a mechanism that can automatically keep
 up the integration patches and convert feature branches to an
 integrated source tree via a patch series, I'll gladly eat crow and try
 to convert over.  But I still want to keep pure feature branches, and I
 do not want to have to worry about integration all over again at every
 upload.

Unless new information comes up on this thread, I am done.

manoj
-- 
Reinhart was never his mother's favorite -- and he was an only
child. Thomas Berger
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow <[EMAIL PROTECTED]> said: 

> On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
>> David Nusinow <[EMAIL PROTECTED]> writes:
>> 
>> > The problem is that you and Manoj assume that this is the only way
>> > to do things. I don't believe this. Pierre Habouzit has been
>> > experimenting with an alternative method of feature branches that
>> > exports to a linear stack of diffs just fine. Just because Manoj is
>> > doing something one way right now doesn't mean it's the only or
>> > even the correct way to do it.

I would be interested in details of this, and whether this
 approach works with pure feature branches where the features are being
 developed contemporaneously with each other an upstream development;
 and thus the branches overlap both temporally and in code space.

>> Well, I definitely don't think it's the only way to do things, and
>> I've been one of the people arguing in favor of quilt and exporting
>> to a set of patches.  :) But the "native" Git workflow that people
>> have previously written up for Debian packages doesn't seem to me to
>> linearize very easily, and IMO one of the points here was to let
>> maintainers keep using their native workflows and use the package
>> format for interchange.  Changing the workflow to allow easier export
>> to a particular package format seems to be going the wrong direction
>> to me.
>> 
>> In other words, I still think a patch-based package format is a good
>> idea and would be very valuable for a lot of what's in Debian, but I
>> have to agree with Manoj's point, based on what I've seen so far,
>> that converting an arbitrary Git or Arch repository for Debian
>> package maintenance to such a package format isn't necessarily easy.

> Ok, that's fair. In the worst case then people who want to use this
> sort of workflow could stick everything in a giant diff like we do
> now, so nothing would be lost.

Or have dpkg understand not just quilt, but git.

I mean, if we are making dpkg understand quilt-as-a-version-control
 system, why not also have it grok a modern SCM like git? (I know that
 trying to get it to understand arch is a lost cause).

Would joeyh's efforts to get dpkg v3 format be a got repo make a
 difference here?

manoj
-- 
Freedom begins when you tell Mrs. Grundy to go fly a kite.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:

>> But there is no such linearization, not in the way that
>>  quilt et al do it. The state of such integration is not maintained
>>  in the feature branches; it is in the history of the integration
>>  branch.

> Is this (the integration branch and its history of changes) not the
> linear sequence of changes that David Nusinow is asking for?

Yes, but you don't, in the general case, completely develop some feature
on a branch and then merge it only once.  You do some work on one branch,
merge it, do some work on another branch, merge it, do more work on the
first branch and merge it again, import a new upstream and merge it into
all of your branches, do some more work on the feature and merge it
again

I can see Manoj's point.  It's not at all clear to me that there's a
useful linearization of the feature branches after that sort of workflow
has continued for a while.

(I'm now maintaining two of my packages using only Git and feature
branches without any patch system so that I can get some practical
experience with this and understand the workflow better.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Ben Finney]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> David Nusinow <[EMAIL PROTECTED]> said:
> 
> > No matter what you want to say about your feature branches, you
> > *must* apply them in a linear fashion to your final source tree
> > that you ship in the package. This is no way around it.
> 
> But there is no such linearization, not in the way that
>  quilt et al do it. The state of such integration is not maintained
>  in the feature branches; it is in the history of the integration
>  branch.

Is this (the integration branch and its history of changes) not the
linear sequence of changes that David Nusinow is asking for?

>  And the integration branch does not keep track of what changes come
>  from which branch -- that is not its job.

Doesn't each commit message in the integration branch's history state
what merge you were performing at each revision? You've previously
described your workflow as one where you carefully integrate each
feature branch separately into the integration branch. Do your commit
messages in the integration branch not state what individual feature
branch you're merging in?

It seems to me that the analogue to a linear sequence of patches is
the revision history of your integration branch. Granted, this doesn't
give patches against a pristine upstream except from some initial
state.

-- 
 \ "Some mornings, it's just not worth chewing through the leather |
  `\  straps."  -- Emo Philips |
_o__)  |
Ben Finney

___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow <[EMAIL PROTECTED]> said: 

> On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>> Now, you are trying to make me go towards a mechanism I think is
>> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>> shaky linear patch series) as opposed to pure, independent feature
>> branches, for benefits I still think are dubious, so expect serious
>> push back.  Especially if for every upload I'll have to redo all the
>> integration work of the past; ain't gonna happen.
>> 
>> I am not trying to convince you of the error of your ways.  Please
>> desist trying to convince me of mine.

> No one, not me, nor anyone else in this thread that I've seen, is
> saying that you should abandon your sytem. What we want is a
> consistent method of dealing with differences from
> upstream. Currently, we have one giant .diff.gz, which people hack
> around either with patch systems or vcs's. If we switch to something
> other than a monolithic .diff.gz on top of a .orig.tar.gz, then we win
> because currently we just have a lot of chaos.

So far, this is OK. The devil, though, lies in the details.

> No matter what you want to say about your feature branches, you *must*
> apply them in a linear fashion to your final source tree that you ship
> in the package. This is no way around it.

But there is no such linearization, not in the way that quilt et
 al do it.  The state of such integration is not maintained in the
 feature branches; it is in the history of the integration branch.  As
 each feature branch was created or developed, if there were any
 conflicts, these conflicts were resolved in the integration branch. And
 the integration branch does not keep track of what changes come from
 which branch -- that is not its job. And it does not keep the
 integration patches up to date either -- that again is not its
 job. Details below.

There are only Two use cases I care about. A) Feed each pure
 feature to upstream as an up to date patch against current upstream --
 this is what the feature branch does. B) Have an integrated source of
 all features ready to compile for Debian -- and easy to keep updated
 with lates revisions.  This is the task of the integration branch.


> This idea, a linear stack of changes one on top of the other, is the
> commonality between every one of the different means of handling
> changes to upstream, be they maintained by a patch system or a
> vcs. What we want is to stanardize this concept so that our general
> tools like dpkg are aware of it.

This is where we start to differ. More on this below.

> Given what I know about your system, the only change you would have to
> make is that instead of integrating directly in a final branch, you
> generate a diff and throw that along with the diff's name in to
> debian/patches.

I do not think you have thought it through.  Let us try seeing
 how this will not work: Say I have have feature branches A-F.  When
 development happens on branch A that requires some conflict resolution
 on the integration branch, I do the resolution, and fix up the
 integration branch.  The fix applied depends on what order the features
 were merged in -- and this is not something I need to keep track of, so
 I do not.

 As more development happens, and non-overlapping
 changes in the same area occur, the patch would no longer apply.  Other
 feature branches may make changes in the area; and again, make the old
 patch obsolete.

The a new upstream version comes along, and more changes
 happen.  By this time, the old patch will not apply even to
 upstream. Now rinse and repeat -- the patch you blithely threw into
 ./debian/patches is just dead bit by now.

> That's it. It could be totally automated from your
> current setup without much work, if that's what you want.

I don't think this can be automated.  However, if you think you
 can solve the problem, I'll stand down my objections.  Love to see it
 demonstrated first.

Indeed, the only way to redo the information in the integration
 branch is to start with the original upstream, from several years ago,
 determine which feature branch was merged in what order, what order any
 improvements were applied, redo the conflict resolution patches, redo
 the upstream version updates in the correct order, and get to the
 current integration branch.

Heh. Good luck.

> This is not making you give up anything, it's about improving the base
> standard so everyone can get more information without learning a
> zillion different patch systems and vcs's. As a result, we can focus
> on improving the code itself instead of the process of managing the
> code.

> So, in summary, stop trying to act like you're being forced to do
> something that's going to hurt you. No one is taking away your toys.

Words. Lets us see some code, eh?

manoj
-- 
When a man knows no this shore, other

Re: How to cope with patches sanely

[Guillem Jover]

On Sat, 2008-02-23 at 09:08:23 -0600, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said: 
> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
> 
> Currently vapourware, no?

I want to clarify this, as I've seen it mentioned several times on this
thread. dpkg-source supports extracting Wig&Pen since etch. The missing
bit is source package generation (I posted a proof of concept script to
convert quilted source packages to debian-dpkg [0]).

regards,
guillem

[0] 
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 16:58:01 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said: 

> On Sat, Feb 23, 2008 at 03:08:23PM +, Manoj Srivastava wrote:
>> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said:
>> 
>> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> >> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> >> <[EMAIL PROTECTED]> said:
>> >> > That does not help me during an NMU from the source package.
>> >> 
>> >> For an NMU of one of my source packages, if you can't deal with
>> >> the distributed SCM, then you need not worry about differentiating
>> >> the feature branches, fix the source conflicts, upload. I'll deal
>> >> with fallout.  Comes with the territory.
>> 
>> > If you're applying 10 to 20 different feature branches to your
>> > upstream, then that all comes to the NMU'er as one giant diff. This
>> > obviously sucks and it's what we've been complaining about Ubuntu
>> > doing to us for years. We can do better.
>> 
>> I have hear you say this before, but I am not convinced that the
>> situations are really similar.  You see, with Ubuntu, I do not see
>> any place they provide the information in a nice separate area, even
>> using their preferred SCM, bzr.
>> 
>> That is not the case when using featrure branches, the NMUer can get
>> the information they need.

>   Not really, he needs to grok your $SCM, and well, really, nobody but
> you (and his author maybe, and even that is unsure) grok baz. And not
> even everybody groks git that I'm so fond of.

If you want to NMU a package, and ituses CDBS, you need to
 understand CDBS. If it uses dpatch, you need to understand dpatch.
 Same with quilt.

You only need to understand tla and git if you need to keep
 track of the independent features in the the package development; which
 is an issue only for maintainers (not security NMUers, who are rightly
 more concerned with fixing the security hole in a timely fashion).

>   Having a clean exchange format where _anyone_ groking diff, ls,
> $EDITOR, their shell and some as basic tools is much much
> better. Nobody asks you to _work_ with those, it would be just plain
> great if you just could generate those instead of a big bloat of
> unreadable diff (maybe your packages don't have megabytes of diffs,
> but as soon as you relibtoolize a package, they do).

It is non-trivial to generate a linear series of patches from a
 set of pure feature branches.  If anyone thinks it is indeed trivial,
 and they can implemet a general solution, I'd be happy to stand
 corrected, and will use the tool. I don't think, with my experience of
 pure feature branches, that it is as trivial as the people painting
 this bikeshed think it is.

manoj
-- 
If your life was a horse, you'd have to shoot it.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[David Nusinow]

On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
> Now, you are trying to make me go towards a mechanism I think is
>  inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>  shaky linear patch series) as opposed to pure, independent feature
>  branches, for benefits I still think are dubious, so expect serious
>  push back.  Especially if for every upload I'll have to redo all the
>  integration work of the past; ain't gonna happen.
> 
> I am not trying to convince you of the error of your ways.
>  Please desist trying to convince me of mine.

No one, not me, nor anyone else in this thread that I've seen, is saying
that you should abandon your sytem. What we want is a consistent method of
dealing with differences from upstream. Currently, we have one giant
.diff.gz, which people hack around either with patch systems or vcs's. If
we switch to something other than a monolithic .diff.gz on top of a
.orig.tar.gz, then we win because currently we just have a lot of chaos.

No matter what you want to say about your feature branches, you *must*
apply them in a linear fashion to your final source tree that you ship in
the package. This is no way around it. This idea, a linear stack of changes
one on top of the other, is the commonality between every one of the
different means of handling changes to upstream, be they maintained by a
patch system or a vcs. What we want is to stanardize this concept so that
our general tools like dpkg are aware of it.

Given what I know about your system, the only change you would have to make
is that instead of integrating directly in a final branch, you generate a
diff and throw that along with the diff's name in to debian/patches. That's
it. It could be totally automated from your current setup without much
work, if that's what you want. This is not making you give up anything,
it's about improving the base standard so everyone can get more information
without learning a zillion different patch systems and vcs's. As a result,
we can focus on improving the code itself instead of the process of
managing the code.

So, in summary, stop trying to act like you're being forced to do something
that's going to hurt you. No one is taking away your toys.

> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
> 
> Currently vapourware, no?

This thread is partially about how to implement this very feature, so
calling it vapor while it's still being planned is unfair.

 - David Nusinow
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Pierre Habouzit]

On Sat, Feb 23, 2008 at 03:08:23PM +, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said: 
> 
> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
> >> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
> >> <[EMAIL PROTECTED]> said:
> >> > That does not help me during an NMU from the source package.
> >> 
> >> For an NMU of one of my source packages, if you can't deal with the
> >> distributed SCM, then you need not worry about differentiating the
> >> feature branches, fix the source conflicts, upload. I'll deal with
> >> fallout.  Comes with the territory.
> 
> > If you're applying 10 to 20 different feature branches to your
> > upstream, then that all comes to the NMU'er as one giant diff. This
> > obviously sucks and it's what we've been complaining about Ubuntu
> > doing to us for years. We can do better.
> 
> I have hear you say this before, but I am not convinced that the
>  situations are really similar.  You see, with Ubuntu, I do not see any
>  place they provide the information in a nice separate area, even using
>  their preferred SCM, bzr.
> 
> That is not the case when using featrure branches, the NMUer can
>  get the information they need.

  Not really, he needs to grok your $SCM, and well, really, nobody but
you (and his author maybe, and even that is unsure) grok baz. And not
even everybody groks git that I'm so fond of.

  Having a clean exchange format where _anyone_ groking diff, ls,
$EDITOR, their shell and some as basic tools is much much better. Nobody
asks you to _work_ with those, it would be just plain great if you just
could generate those instead of a big bloat of unreadable diff (maybe
your packages don't have megabytes of diffs, but as soon as you
relibtoolize a package, they do).

  IOW, I'm totally seconding David here.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpjhva6inLze.pgp
Description: PGP signature
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[David Nusinow]

On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft <[EMAIL PROTECTED]> said: 
> > That does not help me during an NMU from the source package.
> 
> For an NMU of one of my source packages, if you can't deal with
>  the distributed SCM, then you need not worry about differentiating the
>  feature branches, fix the source conflicts, upload. I'll deal with
>  fallout.  Comes with the territory. 

If you're applying 10 to 20 different feature branches to your upstream,
then that all comes to the NMU'er as one giant diff. This obviously sucks
and it's what we've been complaining about Ubuntu doing to us for years. We
can do better.

If you want to use your special custom system then that's fine, but I think
that ultimately shipping things as a linear patch stack in the package
makes a lot of sense because you can provide the NMU'er with the ability to
conceptually see the differences in your branches without having to learn
your DVCS. That way you can still use whatever custom system you want to
manage your packages, but at the same time you present your packages to
others in a way that makes it easier for them to work on.

This argument assumes that dpkg-source -x will apply that patch stack
automatically as well, which has been discussed elsewhere.

 - David Nusinow
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said: 

> On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> <[EMAIL PROTECTED]> said:
>> > That does not help me during an NMU from the source package.
>> 
>> For an NMU of one of my source packages, if you can't deal with the
>> distributed SCM, then you need not worry about differentiating the
>> feature branches, fix the source conflicts, upload. I'll deal with
>> fallout.  Comes with the territory.

> If you're applying 10 to 20 different feature branches to your
> upstream, then that all comes to the NMU'er as one giant diff. This
> obviously sucks and it's what we've been complaining about Ubuntu
> doing to us for years. We can do better.

I have hear you say this before, but I am not convinced that the
 situations are really similar.  You see, with Ubuntu, I do not see any
 place they provide the information in a nice separate area, even using
 their preferred SCM, bzr.

That is not the case when using featrure branches, the NMUer can
 get the information they need.

Now, we should also consider the type of NMU, and the need for
 being able to tell the distinction between different threads of
 development.  As a maintainer, where you are juggling user needs for
 features, and trying to add features, and so on, you do need to deal
 with large changes, perhaps touching a large number of files. Here, it
 do need to tell the lines of development apart, and ensure that all the
 lines of development are indivdually undamaged.

For this kind of NMU, you need to be familiar with the package,
 and yes, you need to be able to keep features apart.

Quilt is suboptimal here, since it can't keep features
 independent; since all feaures are impacted by all other features prior
 to it in the linear chain, but I guess it performs well enough.
 Nothing beats a pure featrure ranch in keeping the features
 independent.

But if you are a security NMUer, you have a short time frame,
 and a very targeted fix to install, and you do not have to keep track
 of independent features, and I believe not having a patched source to
 deal with immediately inder such a use case. The feature branch wins
 again, since dpkg-source -x gives you the sources that are used to
 build from, no special shennanigans needed.

> If you want to use your special custom system then that's fine, but I
> think that ultimately shipping things as a linear patch stack in the
> package makes a lot of sense because you can provide the NMU'er with
> the ability to conceptually see the differences in your branches
> without having to learn your DVCS. That way you can still use whatever
> custom system you want to manage your packages, but at the same time
> you present your packages to others in a way that makes it easier for
> them to work on.

In this day and age a DSCM is not a mere "custom system".  If
 you want to hack on modern packages, you need to be aware of modern
 tools. Being a Luddite is not something I would encourage.

Now, you are trying to make me go towards a mechanism I think is
 inferior (a liner, dependent, and in my opinion, opaque, and somewhat
 shaky linear patch series) as opposed to pure, independent feature
 branches, for benefits I still think are dubious, so expect serious
 push back.  Especially if for every upload I'll have to redo all the
 integration work of the past; ain't gonna happen.

I am not trying to convince you of the error of your ways.
 Please desist trying to convince me of mine.

> This argument assumes that dpkg-source -x will apply that patch stack
> automatically as well, which has been discussed elsewhere.

Currently vapourware, no?

manoj
-- 
You will be singled out for promotion in your work.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Thu, 21 Feb 2008 16:23:10 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
>> The difference here being that feature branches are, in my
>> experience, changes against the pristine upstream source.  The
>> merging of different feature branches is done in some integration
>> branch.  Quilt patches are a dependent series where the merging of
>> changes is inherent in the patch ordering.  Thus it's easier to get
>> an "upstream ready" patch from $vcs than from a series of
>> interdependent patches.

> ... unless feature branches interdepend and you have to store
> dependency information somewhere.

I am not sure you have understood feature branches.  They are
 independent, no matter what the overlap. Each feature branch tracks one
 feature against upstream, no matter how the other features work.

The overlap management is done in the integration branch. This
 is significantly different from a quilt series, as others have already
 mentioned in this thread,which is a dependent series of
 linearized patches; and a change in an earlier feature impacts all
 subsequent patches (and  quilt is good at automating the handling of
 that impact). [[duplicated so this can be archived on the vcs-package
 mailing list as well]]

> "Congratulations, you have just reinvented $patch_manager".

Or the patch manager does integration. *Shrug*.  Someone has to
 do integration sometime.  That is the nature of the beast.  The trick is
 to do it once, and never have to think about it again.

What are the most common cases? 
 A) There is a new upstream delta. In this case, 
1) either there is no conflict in any feature branch, in which case
   the upstream delta applies to each feature branch and integration
   branch with no manual thought required.  Indeed, I have a script
   that does this case for me with one command line invocation:
   arch_upgrade.
2) The upstream change conflicts with a feature. A human can then
   disambiguate that feature branch, and the same change then is
   applied to the integration branch.  Only once did I need to think
   about it.  
3) If more than one feature was affected, then I'll need to
   intervene once for each feature affected, and possibly once more
   for the integration branch.  Again, I think this is the minimal
   disambiguation that is needed.
 B) Development happens on the feature branch.
1) There is no conflict with any other feature.  The delta on the
   feature branch is then applied mindlessly to the integration
   branch.
2) Development on one of the branches conflicts with one or more
   other features. Here, the human has to figure out the difference
   on the integration branch -- once.

So, in my experience, A1 is the most common case, followed by B1,
 A2, B2, and A3. The only time I have to even thing about doing
 something manual is A2, A3 and B2 -- and in those cases, human
 intervention can not be eliminated, no matter what tools you use.

My point is that I never have to even think about different
 features or patch  series except in cases where human intervention is
 indispensable anyway. I like that. I am lazy.

manoj
-- 
Reliable source, n.: The guy you just met.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg

Re: How to cope with patches sanely

[Manoj Srivastava]

On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.20.1722
> +0100]:
>> I have to take care of it manually once.  That is the first time I
>> setup the integration branch that merges in changes from the
>> overlapping feature branches.  This is not a big deal, because the
>> human has to spend some time disambiguating the overlap.
>> 
>> It is critical to me that I never have to spend that time again --
>> and in my case, I never do, since future non overlapping changes
>> (like, say, a new upstream release) produce deltas that apply to the
>> feature and integration branches seamlessly.  I never have to rethink
>> or redo any patches.

> What if feature B depends on feature A

Interesting.  I have never used feature branches where one
 feature was dependent on another feature; feature branches are usually
 "Pure" features.  I'll probably end up as creating feature branches "A"
 and "A+B".

> and a new upstream causes a merge conflict in feature A. Then you have
> to fix feature A, which causes a conflict with feature B. Now you have
> to redo the entire integration, taking care to merge in the right
> order...

The latter part is not true; you just pull into the delta the
 change from feature branch "A+B"; you'll still have to  manually
 intervene twice, once in the "A" branch, once in the "A+B" branch, and
 the latter delta goes into the integration branch.

>> > Yes, just like I want to have feature branches instead of one
>> > gigantic debian branch.
>> 
>> I use my CSM to provide me the changeset: baz diff 
>> 

> That does not help me during an NMU from the source package.

For an NMU of one of my source packages, if you can't deal with
 the distributed SCM, then you need not worry about differentiating the
 feature branches, fix the source conflicts, upload. I'll deal with
 fallout.  Comes with the territory. 

manoj
-- 
Sic Transit Gloria Thursdi.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
___
vcs-pkg mailing list
vcs-pkg@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-pkg