On Sep 22, 2014, at 12:44, Chris Barker <[email protected]> wrote:
> 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. 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. 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. > 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. Web sites are maintained in git all over the place, and their independent pages (documents) are always maintained in a single repository, using branches as needed if changes to different pages are independent but chronologically overlapping. This is a standard aspect of using git. Though I agree it takes a little more conscious thought, because git commits are not natively oriented around file-by-file tracking, so you have to use branching if you want to keep the different sets of file changes distinct. But that's part of the 'fun' of git, as noted above. > 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. 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. John
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
