This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove __ELF__ conditionals

On Tue, 31 Jan 2012, Ulrich Drepper wrote:

> On Sun, Jan 29, 2012 at 08:59, Joseph S. Myers <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]