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

Kevin Raeder raeder at ucar.edu
Sun Aug 4 09:30:10 MDT 2019


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 stragy 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.

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

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.

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.
Genertally 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'".
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.

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/ac3cc64e/attachment.html>


More information about the Dart-dev mailing list