| 1 |
On 10/26/2016 04:02 AM, Rich Freeman wrote: |
| 2 |
> I did suggest that we probably should ban this header until we |
| 3 |
> actually have a DCO because it blurs the lines. However, it isn't |
| 4 |
|
| 5 |
Makes sense, at least strongly discourage, although it likely isn't too |
| 6 |
difficult to do a full ban on git push |
| 7 |
|
| 8 |
> really inferring something that isn't true right now because we don't |
| 9 |
> assign any legal meaning to the header right now. The bigger concern |
| 10 |
> is that it blurs the lines after we have a DCO because people can |
| 11 |
> argue the use of the header was accidental or meant something else. |
| 12 |
|
| 13 |
This comes back to the next part, and instituting a clear timeline |
| 14 |
|
| 15 |
> |
| 16 |
> Whether or not we proactively ban the header, it would probably make |
| 17 |
> sense that if we do institute a new copyright policy including a DCO |
| 18 |
> that we ask all devs to explicitly ack the policy and the meaning of |
| 19 |
> the signed-off-by header somehow (maybe issue a gpg signed statement |
| 20 |
> from a template). It could also be made a part of the ebuild quiz or |
| 21 |
> such so that all new devs ack it. |
| 22 |
|
| 23 |
Exactly (although I'm pleading for people to stop talking about "gpg |
| 24 |
signed".. thats nonsense :) OpenPGP ftw) |
| 25 |
|
| 26 |
> |
| 27 |
> I don't think we need to go nuts with it. Simply getting everybody to |
| 28 |
> ack the policy makes it unambiguous that people understand what the |
| 29 |
> header means. |
| 30 |
|
| 31 |
+1 |
| 32 |
> |
| 33 |
> But, new policy or not the DCO really represents a practice that we |
| 34 |
> should all be doing already. Nobody should be sticking code in a |
| 35 |
> Gentoo repository without ensuring the licenses are compatible and so |
| 36 |
> on. The DCO just represents a best practice that didn't exist when |
| 37 |
> Gentoo started and which most projects now embrace in some form. It |
| 38 |
> isn't that we didn't care about copyright in the past, we just care |
| 39 |
> enough to be a little more formal about it in the future. |
| 40 |
> |
| 41 |
|
| 42 |
+1 |
| 43 |
|
| 44 |
>> > But this doesn't change the fact there is a desire to communicate other |
| 45 |
>> > properties of commits, like the audit trail for QA purposes. |
| 46 |
> Sure. The repository should always make it clear who made each |
| 47 |
> commit, when, and why (with appropriate bug x-refs and so on). |
| 48 |
> Ideally it should somehow capture both who authored the code and who |
| 49 |
> put it into the repository. I think for the most part we're already |
| 50 |
> doing all of this, but I'm sure there is room for improvement (having |
| 51 |
> a bug header in the default repoman commit template probably wouldn't |
| 52 |
> hurt - then they all look the same and you can always delete it or |
| 53 |
> leave it blank if it doesn't apply). |
| 54 |
|
| 55 |
Quality of commit messages certainly leaves something to be desired from |
| 56 |
time to time, and actually having said trail of discussion on bugs.g.o |
| 57 |
|
| 58 |
-- |
| 59 |
Kristian Fiskerstrand |
| 60 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 61 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives