Hi! 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? 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. 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? GrÃÃe, Thomas
Attachment:
pgpbAK9GxNotc.pgp
Description: PGP signature
_______________________________________________ Patches mailing list Patches@xxxxxxxxxx http://eglibc.org/cgi-bin/mailman/listinfo/patches