[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 6/18/13 8:16 AM, Thomas Schwinge wrote:

On Thu, 13 Jun 2013 17:41:51 -0500, Mark Hatle <mark.hatle@xxxxxxxxxxxxx> wrote:
On 6/13/13 5:12 PM, Joseph S. Myers wrote:
On Thu, 13 Jun 2013, Mark Hatle wrote:

I suspect that option groups are an idea whose time is past: that the
space constraints that were relevant when option groups were added six and
a half years ago are not the space constraints that are relevant today,
that today's embedded GNU/Linux systems have vastly more software than was
usual then, and that any residual use for the feature is outweighed by the
extra complexity it introduces, the combinatorial explosion of different
feature combinations, mostly untested and likely broken, and the extra
difficulty it adds to merges from glibc.  Thus, I think it may well be
time to remove this feature, and with it the vast bulk of the divergence
from glibc.

Even though I'm not involved with the regular EGLIBC maintenance work (to
keep options groups from breaking, and more), I do have an idea of the
work Joseph has to do with each merge, and can thus fully understand his
proposal to retire them.  Also, I too assume that they're not as useful
anymore as they were more than half a decade ago.

I think they are still useful, but I agree.  The usage of them is diminishing

You're saying you agree that the cost now outweighs the benefit and it's
time to remove the feature (whether before 2.18, or after 2.18 branches)
rather than to attempt to get some form of it into glibc?

I agree that the use of them is diminishing.  I don't think it's time to remove
them yet.  But maybe in another 6 months to a year we'll have more information.
   It's the 32-bit microcontroller like systems that would still need this.  If
they prove to not be an issue, then I don't have a problem with removing them.

How are you suggesting to get information about their usage?  And/or, how
would we go about deprecating them?

I think this is the tricky part. The best approach is likely send out another email like what Joseph did to start this thread. Also we can take this out to the wider OpenEmbedded and Yocto Project groups.

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.

Would it perhaps make sense to declare option groups deprecated in the
announcement of the upcoming 2.18 release, and remove them right after
the following release (2.19) has been branched, so remove them for the
2.20 release?

I think we need to ping at least the OpenEmbedded/Yocto Project communities and see if anyone will admit to actively using the option groups. If not, then deprecating for 2.19, and removal for 2.20 seem reasonable to me.



Patches mailing list