[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] NEW POLICIES (draft)
From: |
Thomas Lord |
Subject: |
Re: [Gnu-arch-users] NEW POLICIES (draft) |
Date: |
Sun, 3 Oct 2004 11:30:00 -0700 (PDT) |
> From: Harald Meland <address@hidden>
> > 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".
Thanks. That's a typo in the doc which would better read:
> > tla--devo--X.Y+1--base-0
> > is a tag of tla--hub--X.Y--base-0
> > or tla--hub--X.Y--patch-N
or even better:
> > 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.
> 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.
The hub exists as a star-merge hub from which changes to the minor
version can be wholesale-propogated to the major version, which is the
expected case should both versions be being worked on simultaneously.
> [ 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. ]
Thanks.
> 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).
I don't intend to add anything to the GNU Arch project archives which
is not arch related.
> 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.
My intention is to write a series of coding and participation
standards for those projects which I maintain, that's all.
> 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.
I appreciate it and will think about your perspective on it a bit more
--- you might have convinced me here but if so, it hasn't clicked yet.
Thanks,
-t
- Re: [Gnu-arch-users] NEW POLICIES (draft), (continued)
Re: [Gnu-arch-users] NEW POLICIES (draft), James Blackwell, 2004/10/03
Re: [Gnu-arch-users] NEW POLICIES (draft), Matthew Dempsky, 2004/10/03
Re: [Gnu-arch-users] NEW POLICIES (draft), Harald Meland, 2004/10/03
- Re: [Gnu-arch-users] NEW POLICIES (draft),
Thomas Lord <=
Re: [Gnu-arch-users] NEW POLICIES (draft), Andrew Suffield, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Thomas Lord, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Aaron Bentley, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Andrew Suffield, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Thomas Lord, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Aaron Bentley, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Thomas Lord, 2004/10/04
- Re: [Gnu-arch-users] NEW POLICIES (draft), Thomas Lord, 2004/10/04