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

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

Re: [Gnu-arch-users] NEW POLICIES (draft)


From: Harald Meland
Subject: Re: [Gnu-arch-users] NEW POLICIES (draft)
Date: Sun, 03 Oct 2004 16:08:31 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

[Thomas Lord]

> ** Native Component Branching
>
>   Suppose that work on tla-X.Y has just completed.   Among other
>   things, the rules given above imply that, as part of that process,
>   a "version-0" revision has been created:
>
>       tla--devo--X.Y--version-0
>
>   When that revision is created, a new branch will also be created
>   which starts as a tag of that revision:
>
>       tla--hub--X.Y--base-0
>          is a tag of tla--devo--X.Y--version-0

This far I'm following you.

>   If work is begun on a follow-up minor release, that will be done
>   on the branch starting with:
>
>       tla--devo--X.Y+1--base-0
>         is a tag of tla--hub--X.Y--base-0

The current branching.fig seems to tag from "patch-N" rather than
"base-0".

If the hub version is intended to be used for non-merging commits, the
picture in branching.fig seems correct.  If, on the other hand, all
non-merging commits are to occur in the new minor release version, and
the hub version is intended as a star-merge hub *only*, the above text
is correct.

[ branching.fig also names the hub version slightly differently than
  this text; I assume this is a minor glitch, and has attached a
  tarred-up changeset that tries to correct it. ]

>   If work is begun on a follow-up major release, that will be done
>   on the branch starting with:
>
>       tla--devo--X+1.0--base-0
>         is a tag of tla--hub--X.Y--base-0

The same text/figure difference appears here.



I'd also like to say that I'm somewhat surprised by the naming of the
standard-containing version

  address@hidden/stds--rel-src-mgt--1.0

With a category name as unspecific as "stds", it seems one must look
at both the archive name and the category to see that it is somehow
related to tla (or is it Arch it is related to?  I can't tell).

As the policy seems to encourage that contributors re-use the official
category names in their own archives, this rather non-descript
category name doesn't fit too well with the already existing
tla-related categories ("tla", "tla-docs", "hackerlab",
etc.).

Additionally, I think the current split between category ("stds") and
branch ("rel-src-mgmt") somehow "feels wrong"; it can be construed to
imply that if there are several categories of standards documents,
they will all live in the same Arch category, but in different,
non-Arch-related branches.

All this wouldn't be very important if it only was how I did things in
my own archive; however, I think the GNU Arch project is likely among
the first places new Arch users will look for use cases on how the
Arch namespace can be (or even *ought* to be) used.  As the current
policy document seems to strive to provide good Arch use cases, I
thought I'd mention the one issue I consider to be most warty.

Attachment: branching.fig-correction.tar.gz
Description: Correction of branching.fig

-- 
Harald

reply via email to

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