> >I will push back and see if this can be removed as a requirement > >for 1.3 certification. I think we're still going to have to solve > >it by 2.0 though(releases in December)
> I would really like to see that, or at least something besides a test > suite or an FAQ that actually makes this a requirement. This > is not the first time I've gotten the impression that the LSB is > not a very well designed standard. The quality is a factor of enough different eyes getting a look and submitting their comments. There's been much less of that recently than there was in the earlier days. Feel free to point out what else looks awkward - like any open project, contributions make it what it is... The case being discussed (i18n additions to LSB 1.3) is a first effort at something that the LSB is hoping to do much more of in the future: enable other groups to contribute pieces, on which they are the topic experts, to the specification. As one might imagine, there are some issues to work out about how to make that work smoothly. We're still learning. To make a comment on the scope of the i18n changes to commands for LSB 1.3: only LSB-specified commands are affected, and the selection of commands in the LSB is not intended to be a rich user environment, but merely a minimal set needed to enable package installation and postinalls, running of subsystem startup scripts, and the like. I don't think the openi18n team got a lot of traction with upstream maintainers for their patches when they were just representative of that group. Part of the problem seems to have been a bit of a language barrier in describing why the changes were important. Hopefully now with at least one level of that project brought into LSB 1.3, it will be a little easier to stimulate dialogue about the right way to solve the issues raised.
