gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] names -> tagline method transition


From: Tom Lord
Subject: Re: [Gnu-arch-users] names -> tagline method transition
Date: Thu, 29 Jan 2004 12:08:07 -0800 (PST)

    > From: Harald Meland <address@hidden>
    > [Tom Lord]

    > >     > From: Harald Meland <address@hidden>

    > >     > If multiple file -> id mappings already exist "in the wild" (as I
    > >     > suspect might be the case for widely-used projects; e.g. gcc), 
you'd
    > >     > need some kind of file-id aliasing scheme; 

    > > Or, you could just try to discourage that

    > What does "you" in the above sentence refer to?  The upstream
    > (initially not too arch-friendly) maintainer?  Or the person doing the
    > "archification" of the project?

Neither.  It refers to "you, the community" in response to mutliple
people "in the wild" who are "archifying" some upstream project.

If, say, 6 different people independently say "Ok, here is the
archification of GNU sed" but they all use different tags -- vote with
"your" collective feet.

Note that you're _only_ voting on the mostly arbitrary choice of id
tag names.   If you pick A's version, B,C,D, and E can just use those
with no loss in decentralization.

    > Would some ponderings on these issues be considered useful on, e.g.,
    > the "Tracking a project that doesn't use Arch" wiki page?

I think the more useful thing would be to work on tracking some actual
projects -- the general advice about tracking should grow out of that,
organically.



    > > and, when you can't, use names-method changesets to gateway.

    > If I correctly understand what a "names-method changeset" is, it
    > wouldn't work for gatewaying between branches in which non-symmetric
    > renaming have taken place, would it?

No, it would be an ad hoc way to solve a stupid problem that, in
anything but the short-term, should just be killed.


    >> But tagging is an incredibly arbitrary, immaterial choice.  Two
    >> "forks" that don't agree to cooperate in most ways can agree to tags
    >> without requiring much of either.

    > Yes -- assuming that the maintainers of at least one of the forks
    > knows of the other one, and assuming that their choices for tagging
    > method isn't incompatible.

It's the job of "the community" to introduce the two should conflicts
actually arise in practice.


-t





reply via email to

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