[Top][All Lists]

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

Re: [Gnu-arch-users] [MERGE REQUEST] changeset translation preparatory w

From: Colin Walters
Subject: Re: [Gnu-arch-users] [MERGE REQUEST] changeset translation preparatory work
Date: Sat, 29 May 2004 22:12:48 -0400

On Sat, 2004-05-29 at 20:53, Miles Bader wrote:
> On Sat, May 29, 2004 at 06:05:06PM -0400, Colin Walters wrote:
> >  Multiply out the 30 seconds by the number of people, and you
> > have something substantial.
> YEah, but what's "the number of people"?  Certainly not everybody.

I don't have any hard numbers.

> > 2) stuff like {arch}/=tagging-method is *my* source code.  I shouldn't
> > have to use tom names for it.
> It's be great if everything was infinitely customizable, 

I'm not really suggesting it be customizable.  Instead I'm proposing to
default to the way the obviously vast majority of other software out
there names files.  Even inside arch I think it's pretty clear (from
.arch-inventory and .arch-ids) that the { and = are basically just
legacy.  But people who want to keep the tom names should be able to of

In case it's not clear, I am not doing anything with '+' and ',', since
they actually serve a purpose.

> but that's not
> realistic -- everything has a cost, and if a change to make arch behave in a
> way that's more aesthetically pleasing to you 

It's not just aesthetics (although that is definitely a part).  The fact
is my shell hates it too.

> has major negative
> consequences, it may simply not be worth it, if the demand is only a few
> people here and there.

I interact with a lot of hackers, and in talking to them about arch this
is invariably something they mention as something they dislike.  Some
more than others.

> The brief description in your message made what your patch is doing sound
> really hairy; are the additional bugs/code-obfuscation/maintainance issues
> (and besides the cost to tla , non-tla code that has {arch} hard-wired in
> some way will have to be changed too).

It does add the potential for more bugs.  I plan to extend the test
suite significantly to account for this.  I don't think the maintenance
will be too much of a problem if the changes are done cleanly.

Anyways, this has been discussed enough in the past, and I don't want to
spend anymore time arguing about the rationale.  I want to actually fix
it.  Of course we should discuss approaches and technical problems.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]