[crossfire] Updating source file headers

Mark Wedel mwedel at sonic.net
Tue Jul 16 01:59:11 CDT 2013


On 07/15/13 07:54 PM, Kevin Zheng wrote:
> Hi there,
>
> While poking around the sources, I realized that the headers scattered
> around just about every source file need a bit of updating. Here are
> some of the changes that I think should be made:
>
> 1. Let's update the header to be slightly more descriptive. While there
> are many multiplayer games that aren't for X windows, there are even
> more that are.

  I think that is fair (although, I think you meant to say that we should not 
say that X-windows is the key point, although what you say above doesn't quite 
match that)

  Follow up question would be what should the short synopsis of the game be? 
"Crossfire, a multiplayer graphical RPG game"?

  It could also be reasonable that the comment be different based on component, 
eg, the server might make mention it is the server component, while the client 
might make mention it is the client (and in particular the GTK might mention it 
is the GTK only client, etc).


>
> 2. Bumping the copyright dates seems to be a good idea. According to
> SVN, every year from 1999-2013 is a "copyrightable" year, so why not
> update the headers to reflect that? The copyright is applied to the
> project as a whole, not individual source files (based on my limited
> knowledge of copyright law).

  I'm no lawyer either.  I know at work, the copyright year is only updated when 
the file is changed, but I don't know if that is for legal reasons or not (and 
whether it being closed source also makes a difference).

  I'm also not sure the copyright status with a date that predates the existence 
of the file (eg, if the file was added in 2010, whether you can say copyright 
1999-2013 on that file or not)

  In the past, whenever I made a change to a file, I updated the copyright if it 
was out of date.

  The one reason not to update the copyright files is that it just create 
SVN/log churn.  That is to say, at the start of every year, every file would get 
checked in with just a change in copyright year.  From what I have seen, other 
open source projects don't do that (I've sometime gone long whiles between 
updates, and there are still files not modified in those projects).  It also 
means that source browsers or otherwise browsing different versions of a file 
mean that you have a version with no actual change in any way.

  That said, I think I was about the only person that ever updated the copyright 
information, so I'm not sure if just better process to get developers to update 
it as they make changes would help (at work, there are actually checks done to 
make sure copyright is updated appropriate, but it also does thing like style 
checks and a bunch of other checks).  I suppose if we cared enough, one could 
probably make a pre checkin hook that checks for current copyright year.

>
> 3. New comment style for the header. It tries to be more consistent with
> headers I've seen out in the wild. There isn't really any reason for the
> change other than "I like it more."

  Can you give an example of this header?

>
> 4. Maybe we can shorten the 3-paragraph GPL license? Instead, we throw
> them into a top level file called LICENSE and tell users to look at that
> instead. The GPLv2 usage instructions verify that this is a viable
> alternative.

  I'm fine with that.

>
> 5. Take the $Id$ keyword out of the rcsid array if it's not being used.
> We can put it as a one line comment right above/below the copyright
> statement. Alternatively, we don't include it altogether.

  I'm fine with that - if the array wasn't actually commented out, it could 
actually be useful, but in current source, even that isn't really true anymore 
(the svn version is sufficient to know what version of the server is, and if 
someone starts going around mixing different versions of different files, 
chances are having the actual version of those files embedded wouldn't help out 
anyways).

  I suspect that is much more a carryover from the (very old) RCS days (and 
perhaps CVS - can't remember) where there really was not a single version to 
embed into the file, so instead each file would have its own version and by 
dumping that info out, you could effectively figure out how old/new a particular 
instance was.

Now days, I can't really imagine that string being used for much.


More information about the crossfire mailing list