On Thu, Jan 19, 2012 at 01:51:34PM +0000, Nicholas Clark wrote: On Tue, Jan 17, 2012 at 02:35:25PM +0000, Steffen Schwigon wrote:
Nicholas Clark <email@example.com
On Tue, Jan 17, 2012 at 10:33:58AM +0000, Steffen Schwigon wrote:
Not sure whether Disney patches are my only competency :-), however,
before 5.16 the copyright should be bumped to 2012, like in the patch
It's also needed in the README, and probably some other places.
Ack. I added README. Didn't find more such public places.
This is in patch 1, attached.
I've applied this as fdfb76e4ec2559ba. Thanks.
Would you be able to have a dig through the source tree and find out
if there are any other places where the copyright year needs updated?
A separate patch 2, attached, targets coprights in files.
This causes 1 test to fail (t/porting/regen.t)
perly.c etc no longer reflect the perly.y they were generated from, because
perly.y has changed. There's a hash embedded to allow this to be tested
without needing bison. A side effect of this is that one needs bison to
fix this, and I was digging for where I have already got a copy of the
same version of bison installed as last time, so that I don't generate
spurious diffs. Found *that*, but there's something else relevant to fix
first, so I'm working my way back up the stack of yaks before I fix this.
Author: Steffen Schwigon <firstname.lastname@example.org
Date: Tue Jan 17 14:17:13 2012 +0000
Bump several file copyright dates
Sync copyright dates with actual changes according to git history.
[Plus run regen_perly.h to update the SHA-256 checksums, and
regen/regcharclass.pl to update regcharclass.h]
On Wed, Jan 18, 2012 at 12:30:29PM +0000, Nicholas Clark wrote:
I can't be sure either - like most of these things, one discovers new stuff
as one tries to implement it. But:
1: Remembering that the perfect is the enemy of the good, and we don't have
anything currently, a partial "solution" is better than what we have.
So even just README and the part of perl.c responsible for the
perl -v output, and that copyright block at the start of the top-level
*.c and *.h files would be a good start. Get that working
3: Any file not in MANIFEST is generated (somehow) during the build process,
so it's not sane to edit them. It may not be sensible to test them
(directly) - I don't know. Particularly if the "test" is also intended to
be able to edit the files to update them.
(for an example of this see Porting/checkcfgvar.pl, which has a --regen
option, and is called as a test by t/porting/checkcfgvar.t)
I'd suggest seeing if you can get something working for the top level C
files, and worry about everything else later.
I don't know if you've started on a different plan, but I had a bit more
inspiration on what I'd do.
1: git is fast, but not magic, hence asking it for revision history all the
way back to the first commit is still going to be slow
2: things are actually correct currently
3: tests pass when releases are tagged
I think start by working on the assumption that we only need to check for
changes since the last release. This is what Porting/cmpVERSION.pl does.
To cater for special cases such as someone changing the editor blocks
[again :-)] or other stuff we don't really think deserves a copyright year
bump, I think it would work to have the option of using a more recent
commit hash as "start here, known good".
Porting/cmpVERSION.pl uses this to find the most recent tag:
git describe --abbrev=0
So, if for example the hard coded known good commit is
I'd use the output of (something like)
git log blead ^v5.15.6 ^5637ef5b34a3e8caf72080387a15ea8d81b61baf *.c *.h
to find changes, where (obviously) v5.16.0 came from the previous command.
This stops at ^5637ef5b34a3e8caf72080387a15ea8d81b61baf, as it's more recent
than ^v5.15.6. This approach still works without having to edit anything
when BinGOs tags v5.15.7, as the output of
git log blead ^v5.15.7 ^5637ef5b34a3e8caf72080387a15ea8d81b61baf *.c *.h
will stop at v5.15.7 (as it will be more recent than that commit).
And then for each file, find the list of changes, and extract the year(s),
and then check that those years are listed in the copyright. Not worrying
about whether the previous years listed are correct, because you've already
done that manually.