Re: Accelerating Y2038 glibc fixes

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]

Hi Joseph,

> On Fri, 12 Jul 2019, Wolfgang Denk wrote:
> 

Wolfgang went for his holidays, so I hope that you don't mind if I
reply.

> > See for example [1] - there are just 7 lines of "code".  But Joseph
> > does not accept our patches.  The arguments he gives are not on a
> > technical level;  
> 
> The patch is providing a technical specification that is supposed to 
> underpin both subsequent patches in the series and maintenance of
> code in this area of glibc over several years - an area where
> complete clarity of the intended interface is critical.  That the
> specification in question is seriously vague with emphasis on the
> wrong concepts is very much a technical issue.  The code is very much
> the easiest and least important part of this patch.
> 

Yes. We are aware of this. However, we discuss this problem since the
beginning of the year (and yes, I'm aware about your limited time,
which you can spent on this). 

> > instead he says that only a native English speaker
> > who has a with deep understanding of glibc internals and the
> > previous development process will be capable to provide such a patch
> > in an acceptable way.  
> 
> That is not what I said.  I said it makes more sense for someone with
> that familiarity to do the editing - that is, that would enable the 
> specification to achieve consensus sooner than going through a long 
> sequence of patch reviews.

The problem is your limited "time budget" on this issue as well as the
very low interest from the glibc community (as Alistair tries to add
RISC-V Y2038 safe 32 bit port).

Our goal is to add a solid foundation for the Y2038 work, so we would
know the direction where we are heading.

> 
> Writing detailed, precise explanations of exactly how something vague
> is vague and how the concepts referenced aren't quite the right ones
> is itself very time-consuming (listing all the deficiencies in a
> sentence such as "To be more specific - this flag focuses on higer
> level of abstraction, which indicates the system's ability to support
> 64 bit time." in the specification would result in an enumeration
> much longer than that sentence itself), but if you'd rather proceed
> with such reviews we can do so.  Based on previous experience with
> reviews of patches in this series, that would likely take several
> more iterations to get a specification of reasonable quality than
> simply rewriting the text in question.

If you think that it would be better and most of all faster if you
rewrite the description, then I don't mind. 

It would be great if you could do it sooner than latter as this slows
down our development.

> 
> > [1] https://patchwork.ozlabs.org/patch/1114061/  
> 
> This is not the most recent version of the patch posted.

Yes, correct. I must have shared wrong link with Wolfgang.

The most recent version of this patch set (v8):
https://patchwork.ozlabs.org/patch/1117100/

> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]