Updating copyright notices to 2015 for PGDG

On Sat, Jan 03, 2015 at 09:54:16PM +0900, Michael Paquier wrote:

Hi all,

Shouldn't we update the copyright notices to 2015 for PGDG like in
7e04792? I mean those things mainly:
Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
Regards,

I just ran this:

./src/tools/copyright.pl
Using current year: 2015
Manually update doc/src/sgml/legal.sgml and src/interfaces/libpq/libpq.rc.in too.
Also update ./COPYRIGHT and doc/src/sgml/legal.sgml in all back branches.

and did what it said on the current branch.

Please find patch attached.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sat, Jan 3, 2015 at 01:45:37PM -0800, David Fetter wrote:

On Sat, Jan 03, 2015 at 09:54:16PM +0900, Michael Paquier wrote:

Hi all,

Shouldn't we update the copyright notices to 2015 for PGDG like in
7e04792? I mean those things mainly:
Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
Regards,

I just ran this:

./src/tools/copyright.pl
Using current year: 2015
Manually update doc/src/sgml/legal.sgml and src/interfaces/libpq/libpq.rc.in too.
Also update ./COPYRIGHT and doc/src/sgml/legal.sgml in all back branches.

and did what it said on the current branch.

Please find patch attached.

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/06/2015 04:19 PM, Bruce Momjian wrote:

On Sat, Jan 3, 2015 at 01:45:37PM -0800, David Fetter wrote:

On Sat, Jan 03, 2015 at 09:54:16PM +0900, Michael Paquier wrote:

Hi all,

Shouldn't we update the copyright notices to 2015 for PGDG like in
7e04792? I mean those things mainly:
Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
Regards,

I just ran this:

./src/tools/copyright.pl
Using current year: 2015
Manually update doc/src/sgml/legal.sgml and src/interfaces/libpq/libpq.rc.in too.
Also update ./COPYRIGHT and doc/src/sgml/legal.sgml in all back branches.

and did what it said on the current branch.

Please find patch attached.

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

hmm is it intentional that the commit also changed other files?

looks like the commited patch added newlines to various files that had
none before for example:

src/test/isolation/specs/nowait-2.spec
src/test/isolation/specs/nowait-3.spec
src/test/isolation/specs/skip-locked-4.spec
src/test/modules/commit_ts/commit_ts.conf

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4baaf863eca5412e07a8441b3b7e7482b7a8b21a#patch1352

while I do think that the files should have newlines I dont think those
should be added in a copyright bump commit and I think the script might
actually break files where we specifically dont want a newline (afaik we
dont have atm but still)

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

hmm is it intentional that the commit also changed other files?

looks like the commited patch added newlines to various files that had
none before for example:

Specifically, these files had no newline after the last line in the
file.

src/test/isolation/specs/nowait-2.spec
src/test/isolation/specs/nowait-3.spec
src/test/isolation/specs/skip-locked-4.spec
src/test/modules/commit_ts/commit_ts.conf

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4baaf863eca5412e07a8441b3b7e7482b7a8b21a#patch1352

while I do think that the files should have newlines I dont think those
should be added in a copyright bump commit and I think the script might
actually break files where we specifically dont want a newline (afaik we
dont have atm but still)

Well, I am guessing the Perl 'tie' is adding them as there is no
explicit newline added in the script, and the Tie docs confirm that:

http://search.cpan.org/~toddr/Tie-File-1.00/lib/Tie/File.pm

Because the chomped value will have the separator reattached when it is
written back to the file. There is no way to create a file whose
trailing record separator string is missing.

There are probably other scripts that assume all lines end in a newline.
Is it worth changing the copyright script to preserve the lack of
newlines --- I doubt it. I have added a Perl comment about this
behavior, though.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian wrote:

On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

hmm is it intentional that the commit also changed other files?

looks like the commited patch added newlines to various files that had
none before for example:

Specifically, these files had no newline after the last line in the
file.

I don't think we have any files that require not to have a trailing
newline. Do we need an explicit check against it? Seems doubtful, but
then if the need arises, we will break it each year and who knows if
anybody will be vigilant enough to notice. Stefan caught it this time,
but who would normally skim 18000 lines of supposedly mechanical diff
looking for issues? (How did you catch this in the first place?)

This makes me wonder however how wise it is to update the copyright
notices in every single file in the repo. Why do we need this? Why not
abolish the practice and live forever with most files having copyright
2015? (Only new files would have newer years in their copyright
notices, I guess.) Does this provide us with any kind of protection,
and if so against what, and how does it protect us? Since we have a
very clean git history which shows us the exact provenance of every
single line of source code, and we have excellent mail archives that
show where each line came from for all development in the last decade,
this single line of (C) boilerplate in each file seems completely
pointless.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Jan 6, 2015 at 06:12:30PM -0300, Alvaro Herrera wrote:

Bruce Momjian wrote:

On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

hmm is it intentional that the commit also changed other files?

looks like the commited patch added newlines to various files that had
none before for example:

Specifically, these files had no newline after the last line in the
file.

I don't think we have any files that require not to have a trailing
newline. Do we need an explicit check against it? Seems doubtful, but
then if the need arises, we will break it each year and who knows if
anybody will be vigilant enough to notice. Stefan caught it this time,
but who would normally skim 18000 lines of supposedly mechanical diff
looking for issues? (How did you catch this in the first place?)

I am guessing pgindent would also add a newline, but since the spec
files aren't C files, pgindent doesn't tough them.

This makes me wonder however how wise it is to update the copyright
notices in every single file in the repo. Why do we need this? Why not
abolish the practice and live forever with most files having copyright
2015? (Only new files would have newer years in their copyright
notices, I guess.) Does this provide us with any kind of protection,
and if so against what, and how does it protect us? Since we have a
very clean git history which shows us the exact provenance of every
single line of source code, and we have excellent mail archives that
show where each line came from for all development in the last decade,
this single line of (C) boilerplate in each file seems completely
pointless.

I think the copyright update is more of a consistency thing, rather than
something that has a legal requirement. It is hard to see why we would
stop doing it just to preserve missing trailing newlines we don't even
know we need.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/06/2015 10:12 PM, Alvaro Herrera wrote:

Bruce Momjian wrote:

On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:

I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.

hmm is it intentional that the commit also changed other files?

looks like the commited patch added newlines to various files that had
none before for example:

Specifically, these files had no newline after the last line in the
file.

I don't think we have any files that require not to have a trailing
newline. Do we need an explicit check against it? Seems doubtful, but
then if the need arises, we will break it each year and who knows if
anybody will be vigilant enough to notice. Stefan caught it this time,
but who would normally skim 18000 lines of supposedly mechanical diff
looking for issues? (How did you catch this in the first place?)

yeah while the trailing newline thingy does not seem to be a real issue
it still caught my eye when I was glancing at the diff (I was basically
scrolling through it when I noticed this)

This makes me wonder however how wise it is to update the copyright
notices in every single file in the repo. Why do we need this? Why not
abolish the practice and live forever with most files having copyright
2015? (Only new files would have newer years in their copyright
notices, I guess.) Does this provide us with any kind of protection,
and if so against what, and how does it protect us? Since we have a
very clean git history which shows us the exact provenance of every
single line of source code, and we have excellent mail archives that
show where each line came from for all development in the last decade,
this single line of (C) boilerplate in each file seems completely
pointless.

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Stefan Kaltenbrunner wrote:

On 01/06/2015 10:12 PM, Alvaro Herrera wrote:

This makes me wonder however how wise it is to update the copyright
notices in every single file in the repo. Why do we need this? Why not
abolish the practice and live forever with most files having copyright
2015? (Only new files would have newer years in their copyright
notices, I guess.) Does this provide us with any kind of protection,
and if so against what, and how does it protect us? Since we have a
very clean git history which shows us the exact provenance of every
single line of source code, and we have excellent mail archives that
show where each line came from for all development in the last decade,
this single line of (C) boilerplate in each file seems completely
pointless.

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

+1 to that, but I would +2 a script that just did
g/Copyright Regents of Fooniversity/d
etc.

Abhijit et al will probably hate me for referencing this, but here it
goes anyway:
http://toroid.org/ams/etc/updating-copyright-notices

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

+1

Also, now that we're on git it wouldn't be that hard to add commit hooks that prevent (or maybe even fix) trailing LF. If this is somethin pg_indent or other tools would do anyway ISTM it'd be nice to use a hook that fixes it because it would cut down on the size of pg_indent diffs.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Jan 7, 2015 at 8:48 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

+1

Also, now that we're on git it wouldn't be that hard to add commit hooks
that prevent (or maybe even fix) trailing LF. If this is somethin pg_indent
or other tools would do anyway ISTM it'd be nice to use a hook that fixes it
because it would cut down on the size of pg_indent diffs.

... And increase the size of vanilla commits if you do it in the same
commit, or make the git history less readable if you fix them as a
separate commit. It is better IMO to keep the cleanup work in a single
huge commit.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

+1

Unless either of you is a copyright lawyer, your opinion on whether that's
sufficient is of zero relevance.

Personally I think it's just fine if we have some mechanism that forces
text files to have trailing newlines ;-)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/6/15, 6:15 PM, Tom Lane wrote:

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:

I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?

+1

Unless either of you is a copyright lawyer, your opinion on whether that's
sufficient is of zero relevance.

No, but a friend's dad is. I could probably get his opinion on it if that would be helpful.

Personally I think it's just fine if we have some mechanism that forces
text files to have trailing newlines ;-)

Which is what I was suggesting... ;) AFAIK that would be a matter of installing the appropriate hook on git.postgresql.org.

https://www.google.com/search?q=git+enforce+trailing+newline
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers