Installing 'update-copyright' on PQM

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent and Robert (and Andrew) had a discussion about adding
update-copyright to the PQM machine. Their discussion is here:
http://irclogs.ubuntu.com/2010/06/18/%23bzr.html

My rebuttal to that is:

1) Yes, there is an edge case, where I can merge a really old change
   that otherwise needs no modification. And that could introduce a new
   change to the code (only changing the copyright line to add a year
   that would not otherwise be considered changed.)

  a) That is pretty rare (code normally ages a lot in 1+ years)
  b) One could argue to lawyers that the act of merging changes in a
     given year, should cause a copyright update in that year.
     (Aggregation into a larger work seems an act of development to me.)

2) PQM doesn't make changes to code, people do.
  a) True, except we are already thinking to do stuff like news-merge
     which lets some bits of code work be automated by PQM
  b) The whole point is that the person who did the work *failed* to
     update the copyright header correctly (otherwise the plugin
     wouldn't be changing anything.)
  c) Keeping stuff like copyright headers correct seems perfectly suited
     to being done by a robot.
  d) Another option is to change it to be a commit-allowed check.
     (copyright header must be correct, or the merge is rejected) I'm
     sure that will be received as warmly as the "no trailing
     whitespace" check was received.

3) if 'bzr commit' wouldn't add a new node to the per-file graph, then
   update-copyright shouldn't be touching the file.

  a) Again, if I modify a file in 2010, but fail to update the copryight
     line, the copyright line is now incorrect, regardless of the fact
     that there is no content-merge that needs to be done.

  b) In my original testing, most of the files were already incorrect
     anyway. For example, the Copyright line says 2005 only, but then
     the file was modified in 2006, and the code landed in 2010. So no
     content modifications since 2006. However, to correct the Copyright
     header to say 2005, 2006, *I have to change the content*, which
     will cause it to include 2010.

The main point, though, is:

4) We currently try to handle Copyright lines manually, and we are doing
   a pretty poor job of it. While there are some edge-cases that
   update-copyright gets wrong, it gets *far more* main cases correct
   than we've been doing ourselves.

   a) It is very common to copy a Copyright header from another file
      into a brand new file. Suddenly that new file claims to be
      copyrighted since 5 years ago.

   b) It is also very common to *not* update a Copyright header when a
      file is modified. (If this wasn't the case, update-copyright
      wouldn't be affecting so many files.)


I don't have a great answer for the Merged content from 2005 but no
other changes are present case. Also note that in my testing, most of
those cases *already* had incorrect copyright lines, and to correct the
copyright in 2010, requires changing the content in 2010, which would
cause it to think the file was modified in 2010.

The only way to handle it would be to actually analyze the diffs for
each change (at least 1 per year) and see if there was actual content
change, vs something like "correcting the copyright headers".

Also consider that we recently changed all of the GPL copyright stanzas
to include the new FSF address, and we also changed a huge number of
files to strip trailing whitespace. Should those changes also be omitted
from a Copyright year update?

If the answer is yes, then both Vincent and myself should stop using the
plugin at all, since it will be giving bad results. I still content that
(4) is the predominant case, though.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwiUMUACgkQJdeBCYSNAAO7gwCfenbcFzvi26IhcRY3nHLdtAkd
ECkAoMx2c2fm1BZoiAmcgWzNEVNmaThX
=bsXS
-----END PGP SIGNATURE-----