[Dart-dev] want your input on DART repository changes

[Tim Hoar]

My responses follow Kevin's questions/comments.


Tim Hoar
Data Assimilation Research Section
National Center for Atmospheric Research
thoar at ucar.edu
303.497.1708


On Sun, Aug 4, 2019 at 9:30 AM Kevin Raeder <raeder at ucar.edu> wrote:

> Tim,
> thanks for organizing names at this opportune moment.
> Here are my questions and thoughts.
>
> For the big picture, are we moving away from the strategy of
> "release after major improvements and name it after an island"?
> Is the alternative to just tag a version of the public git(hub)
> master, after it has passed all the tests?
> The naming strategy for the future could or should determine
> the renaming strategy for the old stuff.
>

As per the release strategy,  naming things after islands and then
re-releasing things with the same name can create confusion. Most
everything uses 'semantic versioning', which I describe at the end of the
following document:
https://docs.google.com/document/d/1SFBt7YT0yZ7o2BD4_3CEhKNK_ZfGDCrhR9gr-EoAFcM/edit
 'DART_conversion_process'      I'm proposing a    V x.y.z  approach, and
have a table that converts our svn releases to the  semantic versions.

The timing and motivation of when to create a release stays the same. Yes,
tagging a version of the public version is a 'release'. Whether we name it
after an island or use semantic versioning - or do something like what
apple does ('Mohave' is  OSX 10.14.5)  was something I was going to discuss
next week or so. I view that as a separate issue from what we name our
branches.

Are we abandoning the "trunk" terminology in favor of "master",
> even though we're keeping git's "branches"?
>

That is my porposal. Considering we have not been using 'trunk' for several
years now, and had to rename our primary branch as 'rma_trunk', it seems to
me that 'rma_trunk' fulfills the git role usually filled by 'master'.


> I'm not such a fan of "classic" because it implies to me
> some sort of standard, tried-and-true, always ready version,
> while this version is more like "the old version you might
> want to use if we didn't upgrade the part that you want."
> My alternative would depend on whether we continue to use islands.
>

No help.  I actually thought about starting these with 'zzz_'  so they
would appear as the last set of branches when people listed the branches or
used the pull-down menu of branches  on GitHub.


> Dropping 'rma_' sounds good.  Whether it is replaced by something
> to denote Manhattan (or later release or tag names) depends on
> our development strategy for the future.
> Generally it's nice to have branch names
> that communicate what's in them; the original version,
> the major modification or project, etc., but it takes
> some discipline to merge a branch back into the trunk
> before its name becomes outdated.
>
> If rma_trunk is the thing that was released as Manhattan,
> then I'm fine with "The svn 'rma_trunk' branch will be named 'master'".
>

Exactly.


> I'm very tripped up by
> "(the traditional name for git development branches)"
> My understanding of master is that it is the base
> from which development branches are made.  It is not
> modified until all the development work is done
> and merged into the master.
>

What I was trying to convey is that 'master' is to git what 'trunk' is to
svn.  Subsequent branches are generally made from 'master', and get
reintegrated into master. I did not mean to imply that master should be for
development, but do mean that master is the 'bleeding edge' in that it is
generally newer than what is released. Sorry for any confusion.


> Kevin
>
> On Sat, Aug 3, 2019 at 5:31 PM Tim Hoar <thoar at ucar.edu> wrote:
>
>> I am in the process of converting the svn DART repository to a git
>> repository that will be available on GitHub.
>> There will be a private GitHub repository for development of branches
>> that have private svn repositories.
>> After I verify the private GitHub repo is working correctly and has all
>> the desired content, we will create another
>> public GitHub repo with just the public branches.
>>
>> This seems like the right time to make some choices.
>>
>> Since a git repo traditionally has all the branches available, I was
>> wondering it it might be appropriate to adopt some
>> sort of convention about branch names.   Should all the branches based on
>> the 'pre-Manhattan' file layout start with a 'classic_'  prefix?
>> It would be easy to document that any 'classic_' branch is in maintenance
>> mode and will not get any more development.
>>
>> There are a slew of branches that use the Manhattan layout ... most of
>> them start with 'rma_'  which means little to
>> most people. Compound that with the fact that there are some 'rma_'
>> branches that use the 'classic' file layout, and you see how
>> things can get misleading.
>>
>> I propose that all the branches with the 'classic' layout get a 'classic'
>> prefix, and any branch that uses the Manhattan layout simply use
>> the branch name ... and we drop the 'rma_' from the branch name if
>> necessary.
>>
>> The svn 'trunk' branch will be renamed  'classic'
>> The svn 'rma_trunk' branch will be named 'master'  (the traditional name
>> for git development branches)
>>
>> Please weigh in with your preferences/opinions as soon as possible.
>> Any and all advice is appreciated.
>>
>> Thanks -- Tim
>>
>> P.S. Also please be aware that the svn repository has been made readonly.
>> We have a working git repository, but I want to
>> make the branch name changes (if necessary) as soon as possible and then
>> I will push to GitHub.
>>
>> Sincerely,  Tim - on behalf of the DART team.
>>
>> Tim Hoar
>> Data Assimilation Research Section
>> National Center for Atmospheric Research
>> thoar at ucar.edu
>> 303.497.1708
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/dart-dev/attachments/20190804/06b1aeec/attachment-0001.html>