[Mageia-dev] Collaboration policy
mageia at colin.guthr.ie
Thu Jun 21 17:22:12 CEST 2012
'Twas brillig, and Per Øyvind Karlsen at 20/06/12 02:05 did gyre and gimble:
> 2012/6/18 Colin Guthrie <mageia at colin.guthr.ie>:
>> 'Twas brillig, and Olivier Blin at 14/06/12 22:25 did gyre and gimble:
>>> David Walser <luigiwalser at yahoo.com> writes:
>>>> Olivier Blin <mageia at ...> writes:
>>>>> Crediting patchs from others by only mentionning the source
>>>>> (i.e. Mandriva, Fedora, XBMC, ...) is not enough IMHO.
>>>>> If we want to give proper credits, we should also mention the author of
>>>>> the patch.
>>>> It doesn't say we don't give credit to the patch author. It just says in our
>>>> package changelog (a.k.a. our SVN commit messages), you mention where you got
>>>> the patch from, because at that level you want to be concise and that's a much
>>>> more useful piece of information.
>>> It says that we prefer to mention "source" over "author".
>>> That's not good enough IMHO if we want to be ok with credits.
>>> The "source" is not the one retaining the copyright on a change, only
>>> the author owns this.
>>> And mentionning an author's name is the minimum reward when
>>> cherry-picking a change.
>> Well IMO, this is a trade off that relates to practical usefulness.
>> The options for the commit message are:
>> 1. Mention the source
>> 2. Mention the author
>> 3. Mention both source+author
>> IMO 3 is too verbose for package changelogs, but I agree it would be
>> nice to be able to do this if it were made concise.
>> I also think that 2 is not ideal as this would then make it harder to
>> record the source. We'd either have to write a comment in the spec above
>> the PatchNN: line or put something into the patch itself to indicate the
>> source. This is typically a good idea anyway (I try to put any fedora
>> patches etc. in their own little section of the spec). If patches are
>> generated from git then you don't really want to add unmanaged extra
>> info in the patch file as when it is regenerated, this information would
>> be lost.
>> The opposite is not true - if option 1 were picked, then the author
>> would typically be included already in the patch itself if it is a git
>> formatted patch. I accept this is not always the case, so this isn't a
>> fool-proof alternative.
>> So, in the end, I'm not against mentioning the author directly in commit
>> messages, but I think it's somewhat impractical and thus it is my
>> opinion that it should not be in the message.
> Then you're mixing two different things, this thing was about credting
> authors, right?
It's not solely about crediting individual authors. It's designed to be
a set of guidelines for working with other groups as well as other
people. It's certainly not set in stone and there are other opinions on
the topic than mine, so I don't want my general take on things to be
seen as anything concrete.
It's also important to note the distinction between two classes outlined
in the document: packages and software. These have to be handled
different and each treated on with their own set of rules (albeit
governed by the same general principles overall).
> But now you're replacing it with practical value in changelogs, which
> is an entirely different issue about a totally different subject!
I agree it would be different if the subject were specifically about
"crediting authors" but it's not. I guess the subject is best summed up
as "collaboration guidelines". There are obviously huge crossovers
there, but there is a distinction and practicalities have to factor too
if people are to be expected to follow it. If it takes ten minutes to do
a complex report on authorship before committing a simple fix, it's
clearly not going to win much favour!
> If you want to actually credit the person doing the work, then you
> need to credit the actual authors of the work itself, a distribution
> is certainly not what to be creditting itself for the work done by
> others, they were the ones who put the distribution together, not the
> distribution who put them together (lacking consciousness, thus no
> assurance needs to fill, desire for recognition not possible).
Well it somewhat depends on how you look at it I think. I don't
necessarily disagree with your statements, but if I look at Fedora's
git, Mandriva's svn or the (horrible) bundle of patches that is the
Ubuntu/Debian diff thingy, then I'm benefiting from the fact that the
distro has collected these fixes and made them available conveniently
for me (with various values of "convenient" with the deb patches!).
Likewise if I simply search a mailing list of an upstream project should
I not credit them for proving a known, easy location for me to find such
Perhaps not, but I certainly appreciate the effort that Fedora et al go
to in this regard and find it a massively useful resource for me when
I'm fixing bugs and hacking on things.
I guess you could argue that you should credit the individual packager
inside Fedora for their work in collecting it together rather than the
generic entity, but again, I personally feel that I am representing
Mageia when I do my packaging and if I manage to unearth a patch from
somewhere and include it in a Mageia package and a Fedora packager sees
that and subsequently uses it, I'm more than happy for this work (of
finding, applying and testing the patch) to be credited generically
under the "Mageia" project (and again, this isn't just about credit,
it's also leaving an audit trail for the future).
> If you're going to push this argument a bit further, for anything else
> of software in the distribution that we've packaged with it, neither
> would the authors of this software be the ones to be creditted for
> their work, but rather the distribution carrying it!
I'm not sure what you mean by this statement.
Typically, in any given package shipped, the individual authors who
contributed code to the (upstream) project are not included in the
(downstream) package changelog. In most software the upstream project
is, by definition, referenced in the software name itself. I would
suggest that any individual who contributed code to the upstream project
does not expect to be named explicitly in any downstream changelog of
the builds of that project (after all that's what the traditional
AUTHORS file that is typically included in the package if for), but
rather accepts that the name of the software itself represents them and
their contribution to it.
In this regard, I see the same being true when taking a patch from
Fedora or Mandriva - i.e. credit the "upstream" generically (I use
"upstream" in quotes here as if I take a patch that is only available in
a fedora package for e.g. systemd, then fedora is the effective
"upstream" for this particular change - perhaps "sidestream" is the
So think of this point as a log of "where I, as a packager, got this
from" rather than anything that explicitly credits individuals. Of
course you may want to follow the chain a little to see if Fedora got it
from somewhere first etc. and if so I think that's fine.
As stated previously however, it is highly desirable to have the actual
author listed inside the patch itself. Git makes this nice and easy and
I don't want to de-emphasis this part of the process.
Again, this is just my opinion and take on things - it's certainly not
> So if in Mandriva, we'd actually were to fully recognize your
> arguments adopt this policy which you propose for Mageia iin Mandriva
> again, we'd have to start mess with all the rest of the software we
> ship to make sure that it credits Mandriva as we're carrying their
As above, I'm not really sure what you'd need to change if Mandriva
adopted a similar set of guidelines. AFAICT all that would be needed is
to ensure that commit messages on packages referenced any "sidestream"
you happened to use. Can you clarify a bit here so I can understand
properly? (or did you maybe mean Red Hat rather than that last reference
to Mandriva above because Mand[riva|rake] was originally based on it?)
Perhaps there is a context problem here too. Are you talking primarily
about package svn commits here (and thus changelogs) or software
> And while I myself actually don't wanna meddle in Mageia's businiss
> (despite mine being meddled in first), I *really* don't think Mageia
> should do so either..
I don't consider this meddling personally. I value your feedback here,
but I don't fully understand some of your arguments so any
clarifications you can provide would be appreciated.
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the Mageia-dev