[Monotone-devel] Re: Linking monotone with the official lua shared library as distributed by Debian

[Tomas Fasth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi graydon, you wrote:
> 
> I agree that it is standard to feed patches upstream, when the 
> patches are obvious, widely wanted, in line with upstream's 
> preferences, etc.
> 
> I disagree that this is required.

I can't recall having made any statement about patch feeding to
upstream being an implied or explicit requirement. May be it was my
poor english that made you interpret my argumentation in such a way.

> and I disagree that keeping local changes which you don't feed 
> upstream is in any way non-standard. the extensive set of patches
>  every distributor keeps is evidence to the contrary, as is the 
> canonical free software definition.

Hm. I doubt neither you or I can really tell exactly how those
extensive set of patches came to be. But my guess is that a majority
of these distribution specific patches are backports of bug fixes
and security related stuff which means they are probably already
incorporated in a coming release of the upstream code base.

I have yet to see a open source distribution who is forking code
just for fun. All changes that is not pushed back to upstream will
surely become a burden that someone have to pay for.

The "Debian Policy Manual" section 4.3 "Changes to the upstream
sources" clearly states:

  If changes to the source code are made that are not specific to
  the needs of the Debian system, they should be sent to the
  upstream authors in whatever form they prefer so as to be included
  in the upstream version of the package.

And further on:

  If you need to configure the package differently for Debian or for
  Linux, and the upstream source doesn't provide a way to do so, you
  should add such configuration facilities (for example, a new
  autoconf test or #define) and send the patch to the upstream
  authors, with the default set to the way they originally had it.
  You can then easily override the default in your debian/rules or
  wherever is appropriate.

I doubt other distributions are that different in this regard.

> http://www.fsf.org/licensing/essays/free-sw.html:
> 
> The freedom to study how the program works, and adapt it to your
> needs (freedom 1). Access to the source code is a precondition 
> for this.
> 
> please understand and accept that every free software author and 
> user has this right, and that it is completely moral to make and 
> keep local modifications, and even to re-publish them.

Of course. I do not contest your right to study and adapt. I kindly
ask you to consider the benefits of communicating changes back to
upstream and trying to make the changes in such a way that it can be
useful in a wider perspective. I do this because it will also make
my work as a package maintainer in Debian easier. I also do this
because I believe in code sharing, not by copy, but by reference.
And I also do this because I believe code changes have more value
the more upstream it gets.

>> I have no intention to apply changes in Debian that is against 
>> the will of upstream authors. Especially since the debian build
>> files is revision controlled within monotone's own repository.
>> 
> 
> 
> oh, I will not play such weird political games; it costs us 
> nothing to host your build files even if we disagree with their 
> content. there's no risk of us deleting or modifying them, and 
> there's no need to take into consideration "where you're hosting"
>  when considering what to put in those files. it's a distributed 
> system anyways.

I'm sorry, it was not my intention to imply that the debian build
files was held hostage. To my feable defense I can only say that
english is not my native language. I was actually trying to say that
I do not wish to make changes against the will of the monotone
developers because I value a good long term relationship higher.

>> But you, as an upstream developer, also need to understand that
>>  there is a world outside the monotone community and that 
>> monotone need to be distributed in a way that conform with 
>> requirements created out of a wider perspective that just a 
>> single software project.
> 
> 
> no, this is incorrect; monotone does not "need to be distributed"
>  in any way whatsoever. it is a bunch of bits, and we are allowed
>  to publish whatever we choose within the terms of the upstream 
> license.

I see. Change "need to" to "should" then. Besides, with
"distributed" I meant "being provided as part of a greater whole".
Anyway, what I was trying to express, once again with apparently a
bad choice of words, is that a large distribution, like Debian, do
have a wider perspective, and that each and every piece of software
that is part of that distribution can benefit from being conformant
to that wider perspective.

> please understand that I do not wish to poison our relationship 
> over this issue; I am very happy debian is packaging monotone, 
> and I want to (broadly) remain compatible with your preferences. 
> I simply mean to point out where you are factually 
> misinterpreting the relationship implied by free sw.

I think we are doing quite well, actually :)

> the correct relationship is "everyone tries to come to agreement,
>  and when they can't they make some divergence". the incorrect 
> relationship is "debian gets to tell everyone how it's going to 
> be".

okay. I can only agree. I'm just not sure where in my letter I can
have implied that Debian wish to dictate how things are going to be
regarding monotone.

> in fact, in free software *nobody* gets to force a particular set
>  of modifications on anyone else. not you, not me, not upstream, 
> not users. everyone has their own copy and can change it how they
>  like. that's the fun part.

eh, yes, sure. It can be very fun to play with source code written
by other people. Or it can be a very confusing experience depending
on the choice of coding style.

I'm not trying to impose restrictions on your freedom to keep a copy
of any kind of open source code. I just wish you could consider the
benefits of collaborating with upstream authors.

- --
Tomas Fasth <address@hidden>
GnuPG KeyId: 0x9FE8D504
Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5asJwYdzVZ/o1QQRAsGkAJ0fo9kYYZbv400yOOLeo5d/STraVwCfagUk
8jOteCl/+VeJD8HNjfWOVMs=
=d+12
-----END PGP SIGNATURE-----