On Sat, Jan 26, 2008 at 03:07:27PM +0000, Pierre Habouzit wrote: > 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.
In addition to that, what is really important is a way to know what in
a package has been added by the maintainer so that upstream,
derivatives, or even completely non-Debian distros can take back from us
easily. So we should have a way to show a series of applied patch (not
related to debian packaging of course). This part is trickier, as there
is (and that was the start of this thread actually ;p) no standard way
to do that.
For example, for the package that I maintain in git, there is two
ways:
(1) I always have an upstream+patches branch, and people can see what
I apply to a source package using gitk upstream..upstream+patches
at any time.
(2) I export this upstream+patches branch as a patch series under
debian/patches which is an almost standard place nowadays.
Though, debian/patches is an export-only directory, not a place where
I perform editing and mofications, and if a NMUer adds patches in there,
it's quite a lot of work for me to integrate it back into my workflow.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpATfCV0uM2H.pgp
Description: PGP signature
