Re: [Gnu-arch-users] distinguished branch name, "clone"

[Colin Walters]

On Sat, 2003-11-08 at 21:37, Tom Lord wrote:

> The spirit of the "implicit mainline" idea is to answer the above open
> questions with:
> 
>       (a) yes
> 
>       (b) perhaps, but it's easier just to pick one pattern that
>           most people will want to use and optimize that

That's a good summary of how I feel.

>       (c) no parameters from the project maintainers -- the arch
>             maintainers will set those to constants.

True.  But it's worth saying that I wouldn't advocate this as a general
rule in all situations.  I do think it makes sense in this situation.

>       (d) so, overarch should just be some new defaults and commands
>             added to arch

As much as we can, and no more :)

> I can't say that that's obviously wrong.   Oftentimes, simplifying the 
> problem you thought you wanted to solve leads to great things.   But 
> my suspician is that it's premature in this case.

Maybe; that's why I brought it up on the list :)

> There's a different (but related) slice through the mainline idea,
> too:  You've seen me make analogies between the arch namespace and
> library cataloging systems (like Dewey Decimal or Library of Congress
> classifications) repeatedly.
> 
> Extending that analogy: the arch namespace really just provides a
> _syntax_ for a cataloging system.  It doesn't provide much of a
> semantics.

Right, that would change with a distinguished branch.

> One idea is to make "the official arch guide to namespace usage" --
> analogous to that multi-volume guide from the library of congress.
> That's the path that the "implicit mainline" hack heads down.

What other namespace issues would go into such a guide?

> Another idea is a bit more like, sigh, XML:  provide a mechanism by
> which anyone can publish their own namespace-usage guide for their own
> little corner of the universe, and anyone else can use all of these
> separate guides as if they were one big one.   That's the overarch
> approach and, although it's a much harder idea to fully develop, it is
> at least closer to the peer-to-peer, we're-all-equals, design of arch
> so far.

Sounds like major overkill :)  At least until we can think of some other
namespace issues that would require such a thing.

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