Re: How to cope with patches sanely (Was: State of the project - input needed)
On Fri, Jan 25, 2008 at 09:59:00AM +0100, Pierre Habouzit wrote:
> For one, I'm not sure the "situation" is that horrible. Second, I
> believe joeyh's proposal to be able to use some DSCM features to replace
> the old diff.gz is an excellent proposal, OTOH, you will have a lot of
> people complaining about having to use git (for his proposal) or $DSCM.
> See alioth, we have mercurial, git, svn, still a few CVS users, arch and
> bzr. There are zealots for at least 3 of them, and people that will
> never want to learn anything but svn.
That's partly why I put effort into providing a compatible .bzr.tar.gz
implementation based on Joey's work there (which I agree would be a
great step forward). While I'd be willing to work on other people's
packages that use git, I'm not fond of git and wouldn't want to use it
for my own packages; but any distributed VCS would be better than the
current mess, and source format 3.0 would allow us to get along even
though we prefer different version control systems. I have no particular
interest in persuading everyone in Debian to use my own preferred
system, and it's not necessary to do so in order to improve the
situation.
> I don't think there is One True Solution, though there are probably
> ways to allow _any_ of the $DSCM to be used (and let's svn rot *cough*)
> and have some Debian specific wrappers to allow the basic operations
> (commit, checkout, ...) to be transparent to the people not knowing
> about a specific $DSCM. E.g. I discovered debcheckout(1) recently that
> uses the Vcs-* headers. This is IMHO the way to go.
Yes. Merge is liable to be trickier since there are a couple of
different possible sets of semantics, but that's much more likely to be
an operation performed by the regular maintenance team than by a
drive-by uploader, so that doesn't worry me too much.
> And well, yeah, you may not be able to understand a package using
> dpatch e.g. because it's a really way too complicated patch system, but
> well, then there is another DD that does, and will be able to provide
> patches. We are a thousand, with very various abilities and skills. It's
> nonsense to ask for everybody being able to do anything in Debian. This
> time is long gone, let's have reasonable goals. We should not strive for
> the "everybody should understand everything" but to a more reasonable
> "everything should be understood and easily modified and fixed by a big
> enough number of DDs"[0].
>
>
> [0] Note that this requirement would more or less disqualifies
> techniques like yada …
One major reason many people object to yada is that it's very easy to
think you've fixed something but then discover that the packaging system
in use reverts or otherwise breaks your change, because the files you're
expected to edit are different from other Debian packages and the
differences are not obvious to those unfamiliar with the packaging
system. So, I would go a little further than my understanding of your
comment above and say that, given a reasonable level of general
knowledge about Debian packaging (which might include standard tools not
yet written) and the basic ability to fix a bug in the upstream source,
it should be straightforward to apply that fix to the Debian package and
produce a valid uploadable result. That is, even if a reasonable number
of Debian developers can figure it out, the system should also be
accessible to people with the relevant programming skills with basic
knowledge of Debian packaging.
The documented process for doing that should not include a massive
switch statement ("if the source build-depends on dpatch, then run
dpatch-edit-patch; if it build-depends on cdbs, then figure out which
patch system is in use and ..."). It embarrasses me that our
instructions to new Debian developers, not to mention third parties who
are keen to use their upstream experience to help Debian, have to
include this sort of cruft. If patch systems must stay around, I would
be happy if somebody could design and write a standard wrapper that
could figure out the differences automatically, and get it into
devscripts.
--
Colin Watson [cjwatson@debian.org]
Reply to: