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

Re: How to cope with patches sanely (Was: State of the project - input needed)

On Sat, Jan 26, 2008 at 02:33:40PM +0000, Colin Watson wrote:
> On Fri, Jan 25, 2008 at 09:59:00AM +0100, Pierre Habouzit wrote:
> >   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.

  Well, in a perfect wold, people would be able when they do a NMU e.g.
to commit into a public branch with a known location, and the regular
maintenance team will be the one that would merge it back into the
packaging mainline.

  IOW in order to perform a NMU, you just need to know how to:
  * checkout sources, debcheckout(1) knows that ;
  * commit your changes, debcommit(1) knows that almost, mr(1) could
    also probably be of help ;
  * publish the changes you did somewhere until the regular maintainer
    fetch (sorry for the git terminology, I'll let readers adapt it to
    their $SCM) this branch, and merge it into their own.

  Those 3 operations can trivially be done through specific Debian
commands without any prior knowledge of the $SCM from the NMUer, while
generating something that _is_ in the workflow of the maintainer. There
is a need for a place to publish random branches in a predictible way
though, a .$SCM.gz is indeed a way, but there probably are other that
don't really require a dpkg change.

  Of course, you can replace NMU with "security update" or alike actions
in the previous text.

> 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.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpeamTUeu1cq.pgp
Description: PGP signature

Reply to: