posix threading plans

Steven J. Hill sjhill at realitydiluted.com
Sun May 6 13:53:31 UTC 2007


> I'm still concerned about the incomplete and undocumented status of merges 
> from trunk into this branch.  If I diff libc/sysdeps/linux/arm/, say, 
> between trunk and branch, I see several changes that are reversions of 
> patches made on trunk months ago, despite the last "Merge from trunk" 
> commit being on 2007-04-21.  This is the issue I explained at 
> <http://www.uclibc.org/lists/uclibc/2006-August/016155.html>: unless every 
> single merge commit (a) merges every change in the relevant range of trunk 
> revisions and (b) states in the log message what those revisions are, it 
> becomes pretty much impossible afterwards to work out what isn't merged, 
> and so which diffs are real changes on the branch (and should be merged to 
> trunk) and which are reversions of changes not merged from trunk (and such 
> reversions mustn't be merged to trunk).
> 
Agreed, I am a little behind right now doing customer releases. I will
gladly type up a status of things if people are interested.

> For this reason, I still think a separate branch based on current trunk, 
> getting only individual logical patches that have be checked line-by-line 
> applied to it, and with no partial merges from trunk made to it, is the 
> way to go.
> 
See below.

> The ARM NPTL work was based on trunk at that time (and subsequently merged 
> from newer trunk) precisely because the incomplete and undocumented merges 
> made it infeasible to work based on the NPTL branch without getting 
> regressions relative to trunk.
> 
No, when I began the NPTL work there was no one from Code Sourcery that
even hinted another architecture was being worked on. There was no
initial collaboration and you guys went your own way. The SuperH people
actually did their work against the NPTL branch and kept me abreast of
the work and made patches and development against the branch.

-Steve



More information about the uClibc mailing list