This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove __ELF__ conditionals
On Tue, 31 Jan 2012, Ulrich Drepper wrote:
> On Sun, Jan 29, 2012 at 08:59, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > What do people think about similarly simplifying the copyright notices in
> > glibc, and doing the automatic start-of-year updates,
>
> No. Since the numbers are usually correct this is additional
> information which is easily available without doing expansive queries
> of the version control mechanism. I used it numerous times to gauge
> whether a certain file could be part of a problem just by looking at
> that information.
Could you clarify what sort of a problem these dates help check for?
Being changed a lot isn't a problem for a file, and nor is not needing
changes for a long time. The only thing I find the dates give is an
indication of how reliable people changing the file have been about
updating its copyright dates - gaps in the list often just indicate a past
omission to add a year when changing the file - which is information of no
independent value in working on glibc.
If a file is *unused* (by any currently supported configuration) then that
is useful information - the file can be deleted and doesn't need to be
updated in future global changes - but copyright dates don't give that
information, since plenty of changes update unused files as well as used
ones. It can be quite non-obvious whether a particular file (directly
under sysdeps/unix/, say) is actually used, directly or indirectly via
#include_next or #include with a full path, or is always overridden by a
more specific file for all current configurations - I'd guess that the
best way to detect that would be to capture information from dependency
files generated in the course of builds for all working ports, then look
at files not mentioned there to see if they are used in some other way
that doesn't show up in the automatic dependencies.
> There is no reason to destroy information like that.
Making things easier for contributors and reviewers is obviously a good
thing - it helps attract more of both and helps them get more done in the
same time. So we should try to understand the downsides of this
particular change better to see if we can find a good way to get the
benefits for contributors and reviewers without making it more difficult
to do whatever is done with these dates at present.
--
Joseph S. Myers
joseph@codesourcery.com