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

Bug#666688: marked as done (upload of multi-option enabled coreutils ls (in time for wheezy))

Your message dated Mon, 2 Apr 2012 14:32:20 -0400
with message-id <20120402183220.GA25224@gnu.kitenet.net>
and subject line Re: Bug#666198: ls: add -y option
has caused the Debian Bug report #666688,
regarding upload of multi-option enabled coreutils ls (in time for wheezy)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
666688: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666688
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Bob Proulx wrote:
> Joey Hess wrote:
> > This is needed for compatability with an early form of shar archive
> > posted to Usenet in the early 80's. There is valuable historical data
> > to be extracted from these, but they often seem to use this -y option
> > to ls that is not present in modern versions.
> 
> This is an interesting compatibility feature.  As such I agree it has
> some merit although how much I don't know.  Put me down as officially
> abstaining from that point.  However:

This was a set up for
http://kitenet.net/~joey/blog/entry/ls:_the_missing_options/

This article http://article.olduse.net/286@Apur-ee.UUCP about COBOL
was edited to create a fairly convincing historical proof of a ls -y.
I think only fairly convincing because it's unclear why a shar would
ever need to ls files, even back in the 80's!

As to the other options, multiple people agree that -e is nearly almost
useful, although none of us can quite find a reason to use it. My bug
report neglected to mention that ls -eR is very buggy. -j is clearly a joke.

-- 
see shy jo

--- End Message ---
Reply to: