[Pkg-samba-maint] Bug#443230: Bug#443230: Bug#443230: Enable net usershare

[Steve Langasek]

On Tue, Nov 13, 2007 at 06:47:54AM +0000, Christian Perrier wrote:

> > time is simply not acceptable at all to upstream and should not be
> > forwarded at this time.  (This based on discussion with Jerry @ UDS, in
> > which he stated it was upstream's policy to not enable additional features
> > by default but that it was fine for distros to make such changes.)

> OK, that sounds fair.

> Some day, I would like to propose a policy for naming patches to
> easily distinguish those that are Debian-specific, those that could go
> in upstream but don't for upstream's policy reasons and that that
> should go to upstream.

> More or less somethign like this. Need to get more ideas, but that has
> proven to be useful for shadow.

So based on a number of factors (my experiences with other packages like
openldap and pam; Joey Hess's enlightening blog entries; past annoyances
trying to debdiff packages with changed patches; drinking the Canonical
kool-aid), I've recently become convinced that in-package patch systems are
really not the way to go at all, and that distributed revision control,
whereby we keep a full local copy of the upstream source plus per-patch
feature branches that let us easily merge changes back and forth with
upstream, is the Right Answer<tm>, and at that point naming patches is no
longer an issue (though maybe naming branches is).

Obviously we're a long way from distributed revision control right now, and
even farther from the "easily merge changes back and forth"; and I don't
want to impose such changes on the rest of the team, I myself have been a
reluctant adopter of distributed VCS and am not yet ready to tackle git in
earnest.  But the first step I would propose in the short term is to keep a
copy of the upstream source in the Debian-Samba svn (... and maybe play with
joeyh's pristine-tar hack?), because that would be a time-saver for me
(svn-buildpackage may have a mergeWithUpstream option for building packages,
but there's no such shortcut when building quilt patches, which means
copying around working directories!).

Do others have opinions on this?  It seems obvious to me that the current
workflow for patch creation is equally onerous for all committers and that
this is the right way to fix it, but maybe someone has some other tricks to
share that haven't occurred to me.

> And you know that my Ultimate Goal in Life is having zero-size
> debian/patches directories..:-) (immediately after having all French
> translations at 100%)

Ah, but we already have several Debian-specific patches, so I don't think
that's ever going to happen. :)

> So, well, I keep the right to split the patch anyway. After all, that
> doesn't hurt kittens....

Absolutely, feel free :)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/