On 24/01/08 at 07:54 -0500, Michael Stone wrote:
> 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.
I don't understand why you think that having a repository to keep the
debian-specific part of the package would make us diverge from upstream.
It's simply a way to make contributions from other developers easier.
Suppose I'd like to make a simple cosmetic change to the packaging, like
fixing lintian warnings, fix a spelling mistake, or something similar.
Which process do you want to follow for this? Should I open a new bug,
with a patch, for each such change? Or send it by private mail? You have
ignored both bugs with patches and private mails in the past. Would that
process work?
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
