From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Tiago St?rmer Daitx <tdaitx@linux.vnet.ibm.com>,
gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix handling of #include files during prologue skipping
Date: Thu, 24 Jan 2013 11:13:00 -0000 [thread overview]
Message-ID: <51011733.8040700@redhat.com> (raw)
In-Reply-To: <20130124062333.GA16749@adacore.com>
On 01/24/2013 06:23 AM, Joel Brobecker wrote:
>> I didn't include one since the header files in gdb.base that I looked at
>> the time didn't have it. I checked it again and noticed that from all 11
>> headers files in there only 1 has a copyright in it
>> (gdb.base/included.h).
>>
>> If a copyright is actually needed I will be happy to include one, so
>> please let me know your answer.
>
> Yes please. My understanding of the FSF procedures is that every file
> which contains significant material should have a copyright header,
> and my stance on this is that we should include one in every file.
Yeah. My opinion is that its just easier to not go through
the trouble of applying some sort of "is there enough significant
material in copyright terms to warrant a header" process. Someone
can always come in later and add more lines to a file that was
originally small enough to not have a header, and just reading the
patch may, and usually doesn't show whether a header is already
present or not. So instead of placing a burden on review of
ensuring that detail is taken care of, and so whether a new header
should be added to an existing file, because the file is now big
enough, I much prefer a policy of "always a copyright header from
the start, even if the file is too small to begin with". It's more
"mechanical" that way.
> Your observation is also correct, and it needs to be fixed eventually.
--
Pedro Alves
next prev parent reply other threads:[~2013-01-24 11:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 20:34 Tiago Stürmer Daitx
2013-01-23 20:44 ` Tom Tromey
2013-01-24 0:52 ` Yao Qi
2013-01-24 3:19 ` Tiago Stürmer Daitx
2013-01-24 3:42 ` Yao Qi
2013-01-24 6:23 ` Joel Brobecker
2013-01-24 11:13 ` Pedro Alves [this message]
2013-01-24 12:56 ` Ulrich Weigand
2013-01-24 13:11 ` Tiago Stürmer Daitx
2013-01-24 14:28 ` Tiago Stürmer Daitx
2013-01-24 15:01 ` Tiago Stürmer Daitx
2013-01-24 15:12 ` Tom Tromey
2013-01-24 20:43 ` Tiago Stürmer Daitx
-- strict thread matches above, loose matches on Subject: below --
2013-01-23 18:39 Tiago Stürmer Daitx
2013-01-23 19:30 ` Ulrich Weigand
2013-01-23 19:38 ` Tom Tromey
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=51011733.8040700@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tdaitx@linux.vnet.ibm.com \
/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