Open Stack

On 05/17/2013 08:57 AM, Russell Bryant wrote:
> On 05/17/2013 08:16 AM, Sean Dague wrote:
>> I'm generally +1 on this, however it's going to be hard to get
>> organizations to agree to this while other orgs are listed in the source
>> files. From an IBM perspective, I've gotten agreement that we're cool
>> with this, as long as it's consistent. A patch work where some
>> copyrights are still listed, but others aren't allowed in, isn't going
>> to fly.
>>
>> My suggestion, is that we declare a flag day (like June 15), and that
>> someone needs to make an objection by then, otherwise this is new
>> policy. We create a new hacking rule that projects can use to enforce it.
>>
>> Then we have a couple of volunteers lined up to generate, and review
>> through mass removals from the code for each openstack/ project, plus
>> flipping on the hacking rule.
>
> +1 on the need for consistency.
>
> In order of my personal preference:
>
> 1) completely accurate and up-to-date copyright headers
> 2) no copyright headers (just the license)
> 3) what we have now (incomplete, inaccurate, out of date)
>
> I'm fine with 1 or 2 ... but big +1 on not 3.

I could equally live with #1 or #2, my preference is #2 just because of 
the amount of extra review and education overhead that #1 is.

While it's easy to enforce not having copyright stanza in a patch via 
hacking rule, enforcing that someone correctly shows up with the right 
copyright stanza appropriate to their org / person, isn't machine 
doable. And it would require a lot of core education as well. I've been 
on both sides of that.

I'm -2 on #3. The current state is a very inaccurate portrayal of things.

> If we're going to #2, I definitely think we just need to remove all of
> it.  If we can't do that, we should just aim for #1 by doing a better
> job of documenting and educating on the expectations here, and having
> reviewers do a better job of checking for it.

Agreed, again, that's where #2 wins for me, we can enforce it in 
hacking, so it makes reviewers life simpler.

	-Sean

-- 
Sean Dague
http://dague.net