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.
ACK.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgp12VfPTOibW.pgp
Description: PGP signature