Обсуждение: Updating copyright notices to 2015 for PGDG
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, -- Michael
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. +
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
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 iswritten back to the file. There is no way to createa file whosetrailing 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. +
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
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. +
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
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. Ifthis is somethin pg_indent or other tools would do anyway ISTM it'd be nice to use a hook that fixes it because it wouldcut 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
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
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
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
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