This is the mail archive of the libc-alpha@sourceware.org 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: Is Y2038-proofing in a glibc roadmap somewhere?


On Wed, 2 Sep 2015, Albert ARIBAUD wrote:

> > First, please see the contribution checklist on the wiki.  In particular, 
> > you should make sure your copyright assignment is in place at an early 
> > stage; glibc reviewers are unlikely to want to look at all at any 
> > substantial changes without an assignment in place.
> 
> I've just received my copy of the copyright assignment signed by the
> FSF. Should I make it available somewhere for the glibc folks to see?

No, we can check the list of assignments on fencepost.

> > Second, I advise starting by posting an extended design document 
> > describing your proposed design and how various issues will be addressed, 
> > to avoid expending large amounts of work on an approach with fundamental 
> > design issues.  I think the basic requirements are clear - a macro 
> > _TIME_BITS=64, that is only accepted in conjunction with 
> > _FILE_OFFSET_BITS=64, that causes affected functions and types to be 
> > mapped to versions using 64-bit time_t, while keeping all existing ABIs 
> > as-is; that is necessitated by the basic requirement of keeping full 
> > compatibility with all existing binaries.  But you need to expand that 
> > summary from sentence length to essay length, making a thorough analysis 
> > of all the issues involved.
> 
> I'd like to start working on the design document, but as I wrote
> before, I think than, rather than posting it to the mailing list, it
> would be better to host it on a Wiki page similar to, for instance,
> <https://sourceware.org/glibc/wiki/PrintfHooksDesign>.
> 
> Is this approach acceptable? If so, then I would need some editor to
> add me (just registered as "AlbertAribaud" on the Wiki) to EditorGroup.

I've added you to EditorGroup.  If using this approach, I suggest starting 
each thread with a link to the specific version of the document being 
discussed in that thread, so it's clear everyone is commenting on the same 
document rather than each person looking at a different version.

-- 
Joseph S. Myers
joseph@codesourcery.com


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