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

[Harald Meland]

[Thomas Lord]

>     > >       tla--devo--X.Y+1--base-0
>     > >         is a tag from tla--hub--X.Y
>
> because the tla--devo--X.Y+1 version may be created long after the hub
> already has revisions.

Thanks for the clarification.

>     > 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.

Re-reading the paragraph above, I see that the wording could have been
clearer; by "non-Arch-related branches" I was thinking of the case of
several branches between which no Arch merges have occured.

I did not try to imply that there would occur branches in an official
GNU Arch project archive that were semantically unrelated to the Arch
project -- though I can see how my wording could be taken to mean
that.  Sorry.

> My intention is to write a series of coding and participation
> standards for those projects which I maintain, that's all.

I'd guessed as much.  What I'm trying to say is that if
e.g. "stds--rel-src-mgmt" and "stds--hackerlab" branches appear in the
same archive, and represent completely disparate (arch-merge-wise)
version-controlled trees, that would conflict with my current
understanding of the "Best practice for using the Arch namespace".

It might well be my current understanding that is wrong, but as I
consider it quite likely that I will look to the GNU Arch project when
I try to decide how best to use the Arch namespace for my own
projects, having an incorrect understanding could prove to be
problematic. :-)

Cheers,
-- 
Harald