Thursday, March 17, 2011

Upstream expectations

Interesting topic here. People always expect from you to do something, but you have got sometimes to say no, as you have limited resources.


...

March 15, 2011 at 08:19  Jeff Waugh says: 
You say “code talks”, yet don’t acknowledge that the code was available largely throughout, and certainly in usable form before alternatives were postulated elsewhere.
Availability is not contribution. I fully acknowledge availability. In fact, I rigorously documented it.
You wouldn’t have the cojones to pull this crap with Linus. Don’t pull it with GNOME.

March 15, 2011 at 08:31  Justyn says:
Can you elaborate on “availability is not contribution” in this context?

Say you write a patch for the Linux kernel.
If you have that change sitting in your git repo, it is not yet a contribution. You haven’t taken it through the conventional channels for contributing a patch to the Linux kernel.
If you blog about it, and even if you’re absolutely sure Linus reads your blog, it is still not yet a contribution. You haven’t taken it through the conventional channels for contributing a patch to the Linux kernel.
If you send your changeset to the Linux kernel mailing list, then you have attempted to make a contribution.
If it’s picked up immediately, you’re a contributor! If you have a discussion about it, change it, and try again, and it’s accepted, you’re a contributor! If you submit a changeset again but it’s still not right, then hey, at least you tried.
Canonical had a bunch of stuff. It was shipped in Ubuntu. It was not contributed to GNOME. It’s as simple as that.

March 15, 2011 at 12:03  @yjmbo says:
So, your thesis depends on this precise definition of “contribution”. If I understand you, you are saying that code is “contributed” only when it is successfully accepted, including when acceptance requires you to change the code in directions that are not in your primary scope.
It seems to me that Mark’s definition is different, and more in line with the standard dictionary definition of the word, in the sense of “a gift”.
Now there is value in a community-specific jargon overloading other meanings of a word, when it leads to denser and efficient communication. But this example I don’t think it is.
With this in mind, there are two versions of your last paragraph there :-
* GNOME did not attempt to use well-known available working code to improve their own project
* It was not contributed to GNOME

OK, then perhaps we should revert to a more useful word, “upstreamed”. Upstreaming is advantageous to both the upstream and the downstream, and it’s not laden with emotional value like “gift”. Every line of Open Source code is a gift in some sense!:)

March 15, 2011 at 12:41  @yjmbo says:
Good; I agree that “upstreaming” is valuable, both as a word and a desire. The careful use of words aids communication:)
Upstreaming is valuable to downstream, at least technically because they don’t have to maintain a divergent patchset as upstream evolves. But if everything a downstream consumer does is upstreamed, what does the downstream have left that differentiates them from upstream itself?
What differentiates Ubuntu from Debian? From a generic OS presenting GNOME? What should differentiate them if not differences in their code? Perhaps a lack of upstreaming is what defines them … which is what you seem to be discussing.

You have asked precisely the most difficult questions at the heart of this debate!:)
These are questions I’ll return to, but I hope you’ll think about them quite a bit in the mean time and let me know what you think.
...


But if everything a downstream consumer does is upstreamed, what does the downstream have left that differentiates them from upstream itself?
Canonical is said to be not contributing to upstream. I.e. it should work for Gnome?

No comments:

Post a Comment