public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@eCosCentric.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Alex Schuilenburg <alexs@ecoscentric.com>,
	eCos Maintainers <ecos-maintainers@ecos.sourceware.org>
Subject: Re: [ECOS] Re: eCosCentric copyright hold in headers
Date: Thu, 08 Apr 2004 14:54:00 -0000	[thread overview]
Message-ID: <407567A2.3040106@eCosCentric.com> (raw)
In-Reply-To: <20040408142145.GL29940@lunn.ch>

Andrew Lunn wrote:
> Should we propose what the new banner looks like?
> 
> Is the basic format of the current banner  OK?

I'd like it to be changed actually. Some of the information parts of the 
banner are _very_ frequently poorly maintained and/or inaccurate and do us 
a disservice. I think the Authors/Contributors bits are ambiguous; and the 
Purpose/Description ditto. It's never really been clear what Date the Date 
is for. I think I fill these in more than most people, but still rarely. 
Contributions very frequently have inaccurate fields here, most annoyingly 
the author.

I think something like the following fields would be better/clearer:

Maintained by: <person responsible for _this_ file, irrespective of what it 
was derived from>

Contributors: <anyone else who's worked on it and wants a mention>
Derived from: <what file/package it was derived from if relevant
Description:

I propose dropping the date entirely partly due to the ambiguity and partly 
because it doesn't tell us anything we can't find out more accurately from 
the changelogs.

I propose dropping the mini-description underneath the filename at the top, 
as it is usually no better than the description further down.

It would require some cunning script-fu to try and squeeze the content 
there now into this style as best as possible, but it would be good to do 
these types of sweeping changes that touch all files once. Of course plenty 
of the existing content is wrong too, but we can fix that piecemeal. For 
example most of the "Maintained by" headers would be filled in on a package 
-wide basis.


> --- ChangeLog   2004-04-08 16:12:54.000000000 +0200
> +++ ChangeLog.new       2004-04-08 16:17:45.000000000 +0200
> @@ -3,6 +3,7 @@
>  // -------------------------------------------
>  // This file is part of eCos, the Embedded Configurable Operating System.
>  // Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
> +// Copyright (C) 2004 Free Software Foundation, Inc.
>  //
>  // eCos is free software; you can redistribute it and/or modify it under
>  // the terms of the GNU General Public License as published by the Free
> @@ -26,9 +27,6 @@
>  //
>  // This exception does not invalidate any other reasons why a work based on
>  // this file might be covered by the GNU General Public License.
> -//
> -// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
> -// at http://sources.redhat.com/ecos/ecos-license/
>  // -------------------------------------------
>  //####ECOSGPLCOPYRIGHTEND####
>  //===========================================================================
> 
> The last bit clearly wants to go since its not been true for a long
> while.

Absolutely. We just didn't want to touch every file multiple times. People 
doing "cvs update" won't like us otherwise :-).

> Should the original RedHat Copyright line be deleted as well? I guess
> leaving it could confuse people into thinking the files are still
> copyright RedHat as well as being FSF.. 

When the assignment is properly made the RH copyright _must_ disappear in fact.

I have a script that munges file headers, that was used in the RHEPL->GPL 
change and other changes before that. It's horrible as it has evolved 
piecemeal over time so it's a real hacky mess so I don't want to publicise 
it here :-). It deals with all the various comment characters ( /* */ 
versus // versus # versus ; versus dnl versus <!-- -->) and differing 
licenses though (BSD stack, host tools, etc.) IIRC.

A perl wizard may be able to do a better job quite quickly though, 
especially if we're to munge the other header fields too - this is one of 
the things perl is good at.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

  reply	other threads:[~2004-04-08 14:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040408101602.GJ29940@lunn.ch>
     [not found] ` <4075305D.8020101@eCosCentric.com>
     [not found]   ` <20040408111939.GK29940@lunn.ch>
     [not found]     ` <407556D4.8080407@ecoscentric.com>
2004-04-08 14:02       ` Jonathan Larmour
2004-04-08 14:20         ` Andrew Lunn
2004-04-08 14:54           ` Jonathan Larmour [this message]
2004-04-08 15:21             ` Andrew Lunn
2004-04-08 15:27               ` Jonathan Larmour
2004-04-08 14:49         ` Alex Schuilenburg
2004-04-08 15:40           ` Jonathan Larmour
2004-04-08 16:31             ` Alex Schuilenburg
2004-05-07 17:11 Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=407567A2.3040106@eCosCentric.com \
    --to=jifl@ecoscentric.com \
    --cc=alexs@ecoscentric.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-maintainers@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).