Since CF conventions are already moved to github, I'd be in favor of
migrating the trac tickets to github as well:
https://github.com/trustmaster/trac2github/blob/master/README
all we would have to do is make sure that the trac users sign up for
github and get their usernames so we could do the mapping from trac
user to github user
https://github.com/trustmaster/trac2github/blob/master/trac2github.cfg#L17
On Mon, Sep 22, 2014 at 3:44 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Mon Sep 22 2014 - 13:53:55 BST
