On Mon, Sep 22, 2014 at 11:29 AM, John Graybeal <
john.graybeal at marinexplore.com> wrote:
> First, to my knowledge the existing 1.6 and 1.7 are in Markdown already. I
> thought that was settled? And the standard names are in XML, and that is
> settled.
>
If so -- great! sorry for the noise! (though managing the standard names
in XML in a version control system will be a bit touchy - but doable, I
imagine)
Rich, before answering Jonathan's question, I want to test one of your
> strategies. You say
> > Since we have two different version tracked documents (the CF Standard
> Name list and the CF Conventions document), we should have two different
> repositories. Then for each repository, instead of multiple entire
> documents tracked separately, we should have just evolving document that
> can be tagged with release numbers when specific versions are approved.
> I'm not a git guru, but it is often the case that Git repositories contain
> multiple tracked documents in a single repository. Their changes are still
> managed independently, on separate branches, unless the changes are tightly
> coupled. (Note there are more tracked documents than just those two, CF has
> several vocabularies that also should be tracked as part of the standard.)
>
> So I want to refine your proposal to say yes, let's use branches, but not
> to split out the pieces of the standard into separate repositories. The
> overhead in maintaining repositories will be high and the benefit low.
>
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.
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. But it would let you put all the issues, discussion, etc al in
on gitHub repo, which would be nice. I don't think there is an obvious
choice here.
Imagine that any trac ticket discussion could be accompanied by a version
> of the standard that showed the proposal under discussion
As Jonathan points out, TRAC tickets and gitHub issues are (or could be )
redundant. I'd suggest going all gitHub for the 2.* discussion, OR keeping
with TRAC and maybe tying it to a git repo (potentially on gitHub) for the
documents themselves.
Personally, I think gitHub and git issues work a fair bit better than TRAC
for this kind of thing -- easier for a broader range of people to
contribute, and I think a bit easier to keep track of. And the integration
between gitHub issues, gitHub Pull Requests, and the git repo itself is
very nice.
-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/ae988650/attachment.html>
Received on Mon Sep 22 2014 - 13:44:49 BST
