I think there are several different issues we're talking about. If we're talking about giving developers credit, and using the modified field, it may be reasonable to do so.
Note that I don't believe 2a of the license applies in the maps in the context you indicate. From my reading, 2a covers the case if someone else branches crossfire and makes changes they need to properly record the differences they have modified them and in what way. I don't read it that the files in the original file have to have that complete change history. And should we even discuss the arch files, we don't have any copyright notice or change notice? I would almost say those are more problematic as those are more likely to be new work. A concern I do have with listing all the modified history in map files is that at some point, for some maps, that could get pretty unwieldy if it is trying to be used as a change log history. That is because for changelog purposes, you wouldn't just keep that last entry, but all of them. So something like: Modified: Mark Wedel, 2008-08-25 Modified: Mark Wedel, 2008-08-21 Modified: Rick Tanner, 2008-08-16 Modified: Mark Wedel, 2008-08-01 .... And could create a very long list (I just look at one map and it had 40+ commits on it over its lifetime). So while this may not be a problem that shows up very quickly, it is certainly something that should be thought about - how long a list is too long? My point about adding in $Id$ strings is that provides a totally clear view of the map having troubles, or what map a patch was made against. It is marginally simpler than having to look at the modified dates and then figure out if the map has been fixed. As for access to source system - that doesn't really make a difference - folks making patches will start from some base, and that would hopefully get included in the diff (maybe the editor should empty the $Id$ string?). For folks running server from tar balls, the maps would still contain revision information, which would likely make tracking down bugs easier (map R9821 has this problem - pretty simple to check if that is the latest). A list of Modified fields doesn't really convey to that user much more information, other than last time the map was modified, unless I have some other reference (like I did a svn update last night, and that modified date is fairly recent, so probably a fairly recent change broke it). But that is really by the date, not by who modified it ($Id$ strings contain date as a note) All that said, if some number of Modified: fields were listed, wouldn't bother me that much. But then if done, I think we might also want to clarify what would be appropriate data there - having a name that one can't associate with anyone in a real basis doesn't add much either. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
