[Top][All Lists]

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

[Gnu-arch-users] RFC: category "truenames" [was: ANN: Linux Kernel Arch

From: Stephen J. Turnbull
Subject: [Gnu-arch-users] RFC: category "truenames" [was: ANN: Linux Kernel Arch Repository]
Date: Fri, 12 Sep 2003 11:47:18 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

>>>>> "Colin" == Colin Walters <address@hidden> writes:

    Colin> On Thu, 2003-09-11 at 13:02, John Goerzen wrote:

    >> I've made available a public Arch archive containing the full
    >> history of the Linux kernel

    Colin> Wow, very impressive.  Just one relatively minor
    Colin> comment...wouldn't it make sense to use an address other
    Colin> than your personal one for the archive?

    Colin> Say address@hidden or something like that.  I would
    Colin> imagine the maintainers would be amenable to
    Colin> creating an alias for it.

I've thought about this.  I came to the conclusion that it doesn't
scale, especially for large mirror archives.

As more people use arch, there are necessarily going to be collisions
in category name space, because arch encourages decentralized
decision-making.  This problem disappears if you decide that a
category's "true name" includes its archive of origin.  This even
allows a single developer to use the same category name for separate
projects, although that seems likely to be perverse.  (But if Tom was
restoring old homes, I could see address@hidden and
address@hidden each having an arch category with
little chance of confusion.)

So I think that a reasonable extension to ensure global uniqueness of
a category would be to keep a history of external tags back to the
archive where the project was first imported.  It would be that
archive that determines the "true name" of the category.

Note that this doesn't have to be a tree or forest, but it (AFAICT) is
a DAG.  So there would need to be a "set-true-name" operation for
categories, with the legal options being roots[1] of the DAG.  This
would allow, for example, address@hidden/linux
(provisionally assuming the name change proposed by Miles) to be
created now.  Then when Arch is officially adopted as the RCS of
Linux, when he starts pulling from Linus's official Arch archive,
there would be a category truename conflict, which could be resolved
either by explicitly accepting the "foreign" patch, or by changing the
category's truename in John's archive.  Obviously John would
acknowledge Linus's precedence, although he might not acknowledge
Miles's (if Miles also maintained such an archive).

Besides being theoretically amusing, is this useful?  Well, from my
point of view, yes.  I wrote in separate posts several times of an
"xemacs" category, but that's clearly bogus.  The category is
"gnu-emacs", because we can share a lot of code.  However, the FSF
would clearly like to have "truename" conflicts raised when pulling
patches from "address@hidden/gnu-emacs" because of
copyright issues.  Similarly, I would like to have the same flag
raised on pulling docs from GNU Emacs because of the incompatibility
of the XEmacs documentation license with the FDL.  (Of course this
would be better dealt with by having separate xemacs-doc and
gnuemacs-doc categories, but that wouldn't raise a flag as arch is
currently implemented AFAIK.)

Also, it would be nice to be able to "officially" merge a
contributor's large-scale branch (eg, the GTK+ port) simply by tagging
their branch (still in their archive) in our archive, and having them
set-true-name.  On the other hand, we could provide an "unofficial"
reference without setting the true name, and attempts to pull patches
from that branch would raise "truename" conflicts.  (I guess that
means that "category truename" would actually have to be kept per
version, a little confusing.)

I suspect this works "naturally" for users.

1. When you first get a revision from a project managed with Arch, its
category truename will be the official one, and that will propagate to
your local archive.  If you create local versions or branches, these
will raise a conflict once, you'll change the truename to the official
one, and that's that.  (This could be an option/query in make-version,
too.)  If you decide not to change, this has the effect of indefinitely
marking your code as "unofficial".

2. In cases where the short names conflict, but the projects really
aren't going to share code, conflicts are a sanity check.  (Think
READMEs and stylized Makefiles such as produced by Imake.)

3. In the case where the upstream is _not_ managed under arch, what's
going to happen?  Most likely (unless there's a rivalry going on
anyway) when you (as a new arch user) pull from someone's archive and
get a truename conflict, you'll choose the "big name" truename.  If
you repetitively get conflicts from a minor archive, you contact the
owner and ask them to change.  In this way, the most common truenames
will tend to propagate across the various archives.  Then when
upstream _does_ convert, you'll see the official truename also
propagate quickly.

4. In the cases where it's desirable to maintain a truename
distinction, it can be done at the expense of some administrative
cost.  So the burden is mostly on those who benefit from the feature.

I doubt it's worth the effort of implementation, but it does help to
illustrate why it's a reasonable idea for the archive maintainer
(whether individual or corporate) to use a maintainer-specific, rather
than a project-specific, identifier.

[1]  Is that the correct name for a node in the DAG with no

Institute of Policy and Planning Sciences
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

reply via email to

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