On Wed, Sep 24, 2014 at 5:23 AM, Jonathan Gregory wrote:
> If a different format would be better for generating the final documents
> in various forms, and is easy to work with, it is worth considering, but
> ...
>
I don't know what tools are being used to manage the DocBook source, so I
can't c
Dear Rich
OK, that makes sense. I would be happy with such a procedure. My concern, as
you understood, was with the "quality control" i.e. the outcome of the
discussion equals what has been done to the document, since it's easy to
make mistakes. On the other hand, we would not have to do this if C
On Wed, Sep 24, 2014 at 3:14 AM, Hattersley, Richard <
richard.hatters...@metoffice.gov.uk> wrote:
> But in that case the model is pushed so far that it's effectively
> emulating separate repos.
...
> Why emulate separate repos when you can have the real thing?
I suppose the reason would be
Jonathan,
> I think that the difficulty in updating the document is not that we have
> inconvenient software for doing and facilitating it. It is the intellectual
> difficulty of working out what the changes should be that makes the process
> slow. When we have agreed a ticket, enacting it in the
Dear Chris, Stephen, et al.
Thanks for your helpful explanations. That helps me to understand.
> 3) We move discussion to gitHub issues, rather than TRAC tickets.
If git has a way to carry out a discussion in public like trac, in which
everyone's contributions are recorded and public and submitte
> standard tagging practice supports this without any difficulty in a single
> repository.
Judging by our comments I suspect we have different perspectives on "standard
practice" for tagging and branching. Perhaps you could elaborate on how you
would see it working?
The nice thing about havin
On Tue, Sep 23, 2014 at 2:16 PM, Signell, Richard wrote:
> I wonder if we might have a webinar to demonstrate/talk about the
> concepts we envision here. We've done a lot of typing, but I get with
> 30 min together online I bet we could end up with consensus.
>
or at least know we're all talking
On Tue, Sep 23, 2014 at 11:47 AM, Signell, Richard
wrote:
> Back in mid-March we had a long discussion on this topic, initiated
> when Richard Hattersley presented a model of what CF could look like
> on github using restructured text and github style versioning. His
> mock-up is still at
> htt
On Tue, Sep 23, 2014 at 9:16 AM, Jonathan Gregory wrote:
> I think I must not have missed a point somewhere. Version control is not
> the
> same as branches, is it.
well, we have a vocabulary issue here:
Applying version numbers to something and what those version numbers mean
is one thing.
O
Jonathan,
I wonder if we might have a webinar to demonstrate/talk about the
concepts we envision here. We've done a lot of typing, but I get with
30 min together online I bet we could end up with consensus.
-Rich
On Tue, Sep 23, 2014 at 12:16 PM, Jonathan Gregory
wrote:
> Dear all
>
> I think I
Dear all
I think I must not have missed a point somewhere. Version control is not the
same as branches, is it. We already have version control and maybe we could
add a third digit to it if we corrected defects between versions. I do not
see a need for branches in developing the convention. In soft
Richard Hattersley
>
>
>
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> Chris Barker
> Sent: 22 September 2014 22:58
> To: John Graybeal
> Cc: CF Metadata List; Gregory, Jonathan
> Subject: Re: [CF-metadata] Proposals for Versioning CF Conventions an
On Sep 23, 2014, at 06:26, Hattersley, Richard
wrote:
>> 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.
>
> Indeed. Given their independent release cycles it would be *much* mo
September 2014 22:58
To: John Graybeal
Cc: CF Metadata List; Gregory, Jonathan
Subject: Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard
Names on Github
On Mon, Sep 22, 2014 at 1:23 PM, John Graybeal
wrote:
I think the key question is are they in sync? If the two documents w
st; John Graybeal; Gregory, Jonathan
Subject: Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard
Names on Github
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/trac2githu
On Mon, Sep 22, 2014 at 1:23 PM, John Graybeal <
john.grayb...@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 inde
On Sep 22, 2014, at 12:44, Chris Barker 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 que
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 map
On Sep 22, 2014, at 12:35, Signell, Richard wrote:
> Does this mean the current CF source is docbook xml?
> https://github.com/cf-convention/repository-cf/tree/master/cf-conventions/trunk/docbooksrc
Sorry, correct -- the site is markup (see
https://github.com/cf-convention/cf-convention.github.i
On Mon, Sep 22, 2014 at 11:29 AM, John Graybeal <
john.grayb...@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! (tho
Does this mean the current CF source is docbook xml?
https://github.com/cf-convention/repository-cf/tree/master/cf-conventions/trunk/docbooksrc
On Mon, Sep 22, 2014 at 3:22 PM, Chris Barker wrote:
>
>
> On Mon, Sep 22, 2014 at 9:45 AM, Christopher Duncombe Rae - NOAA Affiliate
> wrote:
>>
>> La
On Mon, Sep 22, 2014 at 9:45 AM, Christopher Duncombe Rae - NOAA Affiliate <
christopher.duncombe@noaa.gov> wrote:
> LaTeX would get my vote every time.
>
The "problem" with LaTeX is that is it both:
A little to "document" oriented - i.e. not really a data structure
and
Really a language, so
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.
Then, I wasn't sure if Rich's proposal was with respect to the 1.x/2.x
division? Or is it only about the documents inside CF currently? W
Dear Rich
> One of the reasons for moving the CF Conventions and Standard Names to
> Github was so that the community could help support CF development.
>
> The github fork/branch/pull-request process allows contributors to
> submit changes that can be discussed, modified, discussed some more
> a
LaTeX would get my vote every time. RST or Markdown are a little too simple
for a complicated document ultimately destined for hard copy publication. I
would definitely stay well clear of `binary coded' formats like Word or
OpenOffice. Although they have versioning features built in, these are not
On Mon, Sep 22, 2014 at 8:24 AM, Christopher Duncombe Rae - NOAA Affiliate <
christopher.duncombe@noaa.gov> wrote:
> Another point which you did not stress is that with a revision tracking
> system like git / github, the evolution of the document can be tracked and
> if necessary reverting to
Another point which you did not stress is that with a revision tracking
system like git / github, the evolution of the document can be tracked and
if necessary reverting to an earlier version is almost trivial. Features
and new concepts can be introduced and developed, polished and refined on
separ
CF Folks,
One of the reasons for moving the CF Conventions and Standard Names to
Github was so that the community could help support CF development.
The github fork/branch/pull-request process allows contributors to
submit changes that can be discussed, modified, discussed some more
and then even
28 matches
Mail list logo
