Re: [Patches] Any remaining uses of option groups?

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Tue, 18 Jun 2013, Mark Hatle wrote:

> > Are Wind River and the Yocto Project tracking trunk of EGLIBC, or the
> > latest releases, or even just (slightly) older releases?  If not trunk,
> > removing the support for option groups from trunk right after the
> > upcoming 2.18 release, for example, would not have any effect
> > immediatelly for these (presumed) remaining users.
> 
> I'm not sure what the final plans will be.  Usually we track the latest 
> release version, and not the unreleased truck.

That of course makes bitrot more likely.  To avoid such bitrot you really 
need automatic builds that report within days of a merge if any option 
groups have been broken - that's a lot more useful than detecting it six 
months later after a release.  (I notice any breakage of cross-localedef 
that way through Mentor's builds.)

But then, if option groups are only used for releases maybe they should be 
literally "a patch maintained on top of glibc" - something maintained in 
the Yocto context, updated once each release cycle (with appropriate 
testing) but not directly in the EGLIBC repository or involved at all in 
the individual merges from glibc.  Because pretty much every merge 
involves conflicts in Makefiles whenever a testcase is added in glibc, 
given that various existing testcases are conditioned to be enabled only 
if certain option groups are enabled - and when I work out where to put a 
new testcase on encountering such a merge conflict, it's not really much 
more than a guess; it's certainly not based on testing with different 
subsets of option groups enabled to determine accurately what features the 
testcase needs.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches