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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpykf46GtZ4K.pgp
Description: PGP signature