Installing 'update-copyright' on PQM

[Martin Pool]

On 24 June 2010 04:21, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----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

It seems to me that copyright inheres in the text which can move from
place to place or retain a logical identity even while being textually
changed.  So a single copyright statement at the top of the file is
only every going to be approximately correct with regard to date,
though in our case it should be quite accurate with regard to
ownership.  If it's going to be approximate I think it's most
important the outer bounds be at least broad enough.  I don't think
saying that something was changed in 2010 when it had only trivial
changes then is much of a problem.

(Which suggests we could just in January update every file to say
$year but perhaps that's too lax.)

> 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.

I agree.  I don't think I've ever had a change rejected only because
of a copyright conflict but it would be a bit annoying if it was.

I'd actually care much more about getting news_merge turned on there
though, because that really does bite me.

> 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.

I agree with that too.

Looking at the actual bzr-update-copyright code, I see it actually
walks back through the history of the file and makes a copyright line
that mentions every time it changed.  This is a useful function but
not what I would expect to have happen in a pre commit hook.  I would
expect if I'm committing in 2010, then if that year is already in the
copyright line, do nothing, otherwise add it to what's already there.
The "guess what the copyright should be" should be a separate manually
invoked function IMO.

This might account for why update-copyright sometimes seems to be
"fighting" with what ought to be compatible changes.

Arguably what we want is a copyright-conflict resolver not an automatic update.

So overall:
  * +1 to automatically broadening copyright to avoid conflicts
 * -0.5 to deploying this particular algorithm into pqm
 * +1 to getting news_merge into pqm

-- 
Martin