[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: divergence from upstream as a bug

"Bernhard R. Link" <brlink@debian.org> writes:

> * Goswin von Brederlow <goswin-v-b@web.de> [080518 16:09]:
>> The quilt extension is certainly a big improvement and will hopefully
>> unify a lot of patch system using packages after lenny.
> Though I guess there still needs to be a way to get such a patchset
> constructed from non-quilt based work models, especially with things
> centered on history. For example something to tag commits to git
> repository, so some package creating tool can put changes belonging
> together (like a modification and its updates for newer upstreams)
> into a single .diff of such a series. (be that meta-tags in the
> description, automatic utilisation of feature branches, extending the
> git format or whatever git experts can think of or consider worthwile)
> (or perhaps I'm just too stupid to find branch-hopping and manual
> merging manually convenient enough to actually do).

There are 2 distinctly different workflows:

1) stacked patches or branches

You base each patch or branch on the source with the previous patch
applied or branch merged in already. Then you have a nice linear
progression of changes that can be put into /debin/patches/.

If you want to use a RCS I suggest using stacked git or the mercurial
extension instead of actual branches.

2) feature branches

Each feature branche is based on upstream (with few exceptions) and
contains all changes for one feature.

Then you have an integration branche where all feature branches are
merged. The merging generally needs human interaction somewhere in the
history of the integration branch. Doesn't mean every merge needs it

Unfortunately there seems to be no way to generate a patch series from
that other than one big patch for everything combined. The human
interaction stored in the integration branch can't be machine
transformed to make a patch series. It seems that that transformation
is just as difficult as the merge itself.

I think the divergence bugs would be most usefull there. The diff.gz
would not contain usefull patches as all features are mangled into one
patch there. But it would be easy to generate a patch for each feature
branch and send it to the BTS.


Reply to: