[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Any remaining uses of option groups?
- To: Mark Hatle <mark.hatle@xxxxxxxxxxxxx>
- Subject: Re: [Patches] Any remaining uses of option groups?
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Tue, 18 Jun 2013 21:56:23 +0000
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
Joseph S. Myers
Patches mailing list