Re: How to cope with patches sanely
Daniel Leidert <daniel.leidert.spam@gmx.net> writes:
> What I mean is: Say you have addressed 5 different issues in the
> code. I still think it is easier to understand, if 5 separate
> patches are provided instead of one. And tracking each of them be
> checking commits for the initial fix and changes done later to
> update the fix is IMHO not as easy as simply providing a separate
> patch. As long as you maintain the package alone, you probably do
> not have advantages of using separate patches. But say e.g. a
> co-maintainer offers help or you do collaborative maintenance in
> general. Then I think, it is much easier to separate fixes into
> logical patches. And IMHO this cannot be done by just using "good"
> commit messages.
All of these are likely reasons for a developer to choose a patch
management system.
My argument is that they are unconvincing to a developer who is *not*
a primary developer of that package, who does not have familiarity
with the specific patch management system you've chosen, yet who will
need to understand it before making changes to the source code (e.g.
in the case of an NMU).
> > As I pointed out, there are already tools that generate an entire
> > Debian source package, including 'foo.orig.tar.gz' and
> > 'foo.diff.gz', in a single step from a given VCS. Evidently what
> > you ask for is possible, and already indeed implemented such that
> > it is easy.
>
> What I ask for is already possible and implemented: quilt and dpatch
> exist.
You were asking specifically to be educated on how this would be done
with a VCS.
> I read your answer to Raphael, where you point to so called "feature
> branches". This leads to the question, if people should be forced to
> use a special VCS (which is already discussed somewhere else in the
> thread), whereas creating Debian packages never relayed on the usage
> of a VCS.
No, the only thing that a potential developer needs to know is the
method for getting source from the VCS; from that point, they have
exactly what I've been describing: the complete source, ready to edit
and/or build. Even the need for executing a specific VCS command goes
away with the 'Vcs-*' fields and 'debcheckout' becomes available.
> To be honest, your workflow is different to mine. I would need to
> examine your way and compare it to mine. All I can say is, that I'm
> pretty satisfied with my workflow and I'm sure, you claim the same
> for your solution.
Yes, this was never about demanding that people's *workflow* change.
You asked how a VCS-based approach allows change management, I was
explaining based on my understanding of your requirements.
The original discussion remains: about ameliorating the effect *on
other developers* of the internal practices of developers on a given
package.
With a VCS-based change management approach, the impact is minimal to
none: The prospective newcomer or one-time developer does not need to
know anything about the tool, because the source package is already
usable without it. With the patch management schemes you describe,
that developer must learn an arbitrary patch management scheme before
even beginning to look at the source.
--
\ "No wonder I'm all confused; one of my parents was a woman, the |
`\ other was a man." —Ashleigh Brilliant |
_o__) |
Ben Finney
Reply to: