RE: Bug#186140: Bug#206210: diff: does not comply with LSB 1.3 (fwd)
> >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.
Reply to: