On Mon, Sep 22, 2014 at 1:23 PM, John Graybeal <
john.graybeal at marinexplore.com> wrote:
> I think the key question is are they in sync? If the two documents will
> generally get released together with one version number than it makes sense
> to keep them in one repo. But if they are versioned independently, then
> it's a bit hard to manage having them in one repo.
>
>
> The thing that will be hard is using branching in the first place, for
> example while managing multiple proposed modifications of the convention.
> (First, everyone who wants to leverage this approach will have to come up
> to speed on git and branching and all that; then, we'll have to figure out
> if/how we want to publish different branches to different builds.) As of
> today, the rate of change is arguably not high enough to demand that
> complexity.
>
Well, how much you branch is up to how you mange the project, and how
complex it is. While the git maxim is to "branch early, branch often" --
you really don't need to branch much at all if the development of the
documents at hind really is pretty linear.
And gitHub makes it remarkably easy for a new user to clone, make changes,
and submit a pull request, without really knowing what the heck git is
doing under the hood.
Once there, the added difficult of managing two documents is a very small
> bit, if you have a branch called standard_names_dev, and a branch called
> convention_dev.
>
where I envision it getting confusing is using multiple additional
branches, to manage draft changes. Though I suppose branch name conventions
could manage that OK:
At the "top":
std_names_master
convention_master
then other branches should be named somethign like:
std_names_my_cool_proposal
or
convention_an_other_proposal
Though while the standard name table is closely related to the standards
doc -- it's really kind of a separate project --not sure why it needs to be
in the same repo.
You _can_ have different documents in different branches, but that's not
> really how branches were designed to be used, and I think would be a big
> confusing.
>
> I am not sure I understand this. Source code was the original target for
> systems like this, and different source code files (documents) are
> everywhere managed in different branches of a single repository, according
> to their change sets.
>
Sure, but in the usual case there is a single "project" that has a version,
etc. It is a collection of whole bunch of different files, and some of
those may be added and removed in different branches, but usually all of
the branches' essentially represent the SAME project in a different state.
and you would merge in the ones you want to do a release.
That being said, gitHub.io uses a special branch to publish stuff -- so it
can work, but frankly, I find that really painful.
But not a big deal -- either way would work fine.
> Though I agree it takes a little more conscious thought, because git
> commits are not natively oriented around file-by-file tracking,
>
exactly -- a "commit" is the sate of the whole branch (literally, as a
hash...), which usually represents the state of the whole project.
> I agree with all this. If the initial 2.x team is willing to try GitHub
> issues, I think it would be a good chance to see if it is a good way
> forward. But I also like trac so would not be upset if the trac (for
> issues) + Github (for docs) approach was used.
>
If this is an experiment for the CF 2.* project -- then we don't need the
standard name table anyway...
As another note, is the idea here that the CF 2.0 standards doc would be
developed in DocBook XML? That doesn't seem very amenable to community
contributions (anyone could contribute ideas, discussion, etc, but actually
patching the docs would get tricky.)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140922/36a062f0/attachment-0001.html>
Received on Mon Sep 22 2014 - 15:57:56 BST
