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




reply via email to

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