On Thu, Jan 24, 2008 at 07:06:14AM +0100, Lucas Nussbaum wrote:
2. A {svn,git} repository is setup, and write access is given to
interested people. You use this repository when doing uploads. You
commit your changes to it.
I have no desire whatsoever to do this. I consider the upstream
repository to be authoritative, I expect that the debian changeset
should be absolutely minimal, and I think that doing this would raise
the bar for contributing changes rather than making it easier to do so.
I have considered adding Jim Meyering to the uploaders field to make it
clear that I consider development of the debian package to be a closely
collaborative effort with the upstream development. (The main reason I
haven't done so yet is that I don't want to drag him into this soap
opera.) Note that this would only formalize what has been de facto true
for some time: Jim follows the debian BTS & when he responds to a bug I
consider it dealt with (with the obvious need to later package the new
upstream version that includes the fix). Note that historically the
coreutils package has tracked upstream development fairly closely, and
has even included upstream development releases when appropriate (and
probably will again once something sufficiently cleaned up & stable
makes it to testing.) When I create a patch I send it upstream and it
either gets accepted or improved or rejected very quickly. In the
current package there's a grand total of two debian patches: one I'm
still not sure about and will probably drop in favor of a simple
documentation change, and the other was added to meet the IPv6 release
goal but isn't suitable for upstream until I either write or steal the
appropriate autoconf routines for IPv6.
Other packages handle things differently, and I won't question why they
choose to do things as they do. But for coreutils I think it is a grave
disservice to our users and to the community as a whole to have
distribution-specific flavors; portability in the unix world is bad
enough already. I won't say there's no chance of creating another
version control repository, but someone would have to present a really
strong case for why that's better than simply using the upstream one.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
