Package: tech-ctte
Severity: normal
Dearest members of the Technical Committee,
I hereby submit to your attention the "coreutils ls options conflict".
I believe the issue is well-known, so I describe it only briefly below;
feel free to ask if you need more information.
ls is missing several key options, notably -y, -e, and -j.
Patches are available for some amount of time now:
http://bugs.debian.org/666198 adds -y
(necessary for compatability with old shar archives)
http://bugs.debian.org/666244 adds -e
(entangled directory display option, quite nice)
http://bugs.debian.org/666684 adds -j
(suitable output format for twitter, cell phones, other 21st century media)
The inclusion of these features in the archive has been one of the goals
of many of us, for many reasons. For many periods of time, the upload of
such a version of coreutils has been held back due to NACK and inaction
by the coreutils maintainer.
The desire to not pointlessly bloat ls with options is good, but then
this is GNU ls, and it already supports
-aAbBcCdDfFgGhHiIklLmnNopqQrRsStTuUvwxXZ1 [1]. The coreutils maintainer
doesn't seem to be able to complete the review in a reasonable time frame.
The situation has escalated to the point that coreutils upstream, who
favors adding at least the crucial -y option as a hidden option (appropriate
given its compatability use case), is in disagreement with the
Debian maintainer.
As anti-DPL[2], I'm worried about two aspects of this issue:
a) The risk of legitimating the fact that by not acting a developer can
block indefinitely the work of other developers (and possibly of the
entire project when working on a rather far reaching release goal).
b) The risk of a negative impact on project morale if---due to the
reason above rather than a legitimate technical reason---we will miss
the Wheezy multi-ls-option release goal.
I therefore bring before you the issue of whether:
- the coreutils maintainer has the right to block indefinitely accepting
these options into coreutils ls;
- or rather if other interested parties have the right to override his
NACK and go ahead with uploads that would allow project-wide testing
of the multi-ls-option implementation.
Many thanks in advance for your help,
Cheers.
PS I've to point out that timing on this issue is, unfortunately,
critical. The Wheezy freeze is close and according to the release
team we're already late wrt the ideal upload date for coreutils.
The delay is not tech-ctte's fault, of course, but please understand
that a long decision time on your part would be a de facto decision.
I'd appreciate if you could reach a decision on this in a timely manner,
as you've recently done in several other nicely expedited cases.
--
-see -shy -jo
[1] A side benefit of filling in the missing gaps is it will allow the
getopt parameter to be autogenerated, avoiding much complication.
[2] http://kitenet.net/~joey/blog/entry/my_anti-platform/
Attachment:
signature.asc
Description: Digital signature