[Top][All Lists]
[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