Some kernel code-of-conduct refinements [LWN.net]

Greg Kroah-Hartman has posted a series of patches making some changes around the newly adopted code of conduct. In particular, it adds a new document describing how the code is to be interpreted in the kernel community. "I originally sent the first two patches in this series to a lot of kernel developers privately, to get their review and comments and see if they wanted to ack them. This is the traditional way we have always done for policy documents or other 'contentious' issues like the GPLv3 statement or the 'closed kernel modules are bad' statement. Due to the very unexpected way that the original Code of Conduct file was added to the tree, a number of developers asked if this series could also be posted publicly before they were merged, and so, here they are."

to post comments

Some kernel code-of-conduct refinements

Posted Oct 22, 2018 8:36 UTC (Mon) by rav (guest, #89256) [Link] (3 responses)

Indeed, the code-of-conduct refinements were merged in the just-released Linux 4.19. https://lwn.net/ml/linux-kernel/20181022073224.GA5658@kro...

Some kernel code-of-conduct refinements

Posted Oct 22, 2018 15:28 UTC (Mon) by epa (subscriber, #39769) [Link] (2 responses)

So if there is a possible breach of the code, does the version at the time of the breach apply or the latest version? What if the new code is merged into the tree but not yet released? Is it possible to be in breach of the code in one git timeline but not another?

Some kernel code-of-conduct refinements

Posted Oct 22, 2018 18:47 UTC (Mon) by samlh (subscriber, #56788) [Link] (1 responses)

I'm not sure this is a serious question, but in case it is:

The obvious answer is the version in master at the time would apply.

Still, I'd be very surprised if the answer to this question was ever relevant.

If it did make a difference, humans are capable of judging things with nuance - we aren't robots.

Some kernel code-of-conduct refinements

Posted Oct 23, 2018 19:26 UTC (Tue) by epa (subscriber, #39769) [Link]

The obvious next step is for online discussions to move into git too. A recent LWN article asked about replacing mailing lists — well that looks like a nail, too. Then a post can be validated against the CoC that is its most recent parent. If some discussions in a sub-project conflict with a later version of the CoC added to master, that would be a merge conflict.

Finally the developers could be moved into git as well, so any offence taken could be simply reverted.