Re: How to handle Debian patches
On Fri, 16 May 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
>
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.
A VCS surely allows browsing and examining patches. But when I dig in a
VCS history, it's because I have something precise to look up, I will
rarely check it ouf of curiosity. debian/patches/ on the contrary is
something that gets my attention when I unpack a source package.
The other part of the problem depends on the workflow used within your
VCS. As Russ explained, if you use topic branch to keep logical changes,
then you have several relevant commits spread in the middle of multiple
upstream commits and you don't have a single description of the branch
itself.
But don't get me wrong, I'm not opposed to using VCS for package
maintainance (I do it!), I just think that we haven't found the perfect
workflow yet.
Ideally, I'd like something where I maintain my upstream changes in topic
branches and the Debian branch would be another topic branch that just
adds the debian directory (without debian/patches) and debian/patches/ is
auto-generated from the set of topic branches. For this, we probably need
to give some hints to the tool that will create the source package. Those
hints could be in a file debian/source/patch-generation and would contain
the (ordered) list of topic branches with its description and any other
required meta-information.
I know that it will not always work if we have strong dependencies between
the topic branches but I'm not sure we have to optimize for that case as
it shouldn't happen to often, and I prefer such a tool that work in 80% of
the cases than no tool at all and continue with a package that consist of
a giant patch mixing multiple stuff. (Or maybe we'll find a way to make it
work in all cases, that would be even better... maybe we have to define
and respect some relationship betwen the topic branches, have topic branch
B be always based on A, and C on B, etc. so that diff between A-B, and
B-C always end up being applicable one after the other)
> > stating:
> > - a description of the patch and its purpose
> > - the associated bug number
> > - who wrote the patch
> > - where it has been forwarded upstream
> > - sign-off by reviewers maybe
>
> All stuff that you get essentially for free by committing to a VCS.
If that's the case, you can auto-generate that information at the same
time when you generate the patches corresponding to your various branches.
It's great!
> I can certianly see some good benefits to the lines that you're
> thinking, but if this turns into a pile of patches on a website that
> upstream has to manually go find, and rarely does, and a lot of busywork
> keeping the patches up-to-date, and maintaining redundant metadata ... then
> why would I want to use that when I can shoot a mail off to upstream
> with a git-format-patch in it?
Certainly patches.d.o is not meant to replace direct interaction with
upstream developers but it would be a nice service for upstream developers
when the debian maintainer sucks (and it happens...) and also for other
distributions that can benefit from our work.
But when we give away patches, we also like to get patches from other back
so that's why I believe that if we design any patch sharing
infrastructure, we must open it from the beginning to other distributions
so that we actually benefit from it too.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: