river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Release 3.0 merge into trunk
Date Tue, 22 Sep 2015 14:23:29 GMT
Apache’s Git support is just fine, and includes the ability to accept pull requests from
Github, in a way that suits our need to ensure code provenance.  The River Container work
that I did was in the Git repository https://git-wip-us.apache.org/repos/asf/river-container.git.

I’m all for switching to git, but we need to actually discuss it and work out the desired
workflow and project structure.  For instance, git doesn’t really encourage long-lived branches
in a repository.  So, should we have separate repositories for the 2.2 and 3.0 branches? 
Should we split out reggie, outrigger, JERI, etc into their own repositories/deliverables?
 Should we have a set of repositories that reflect our release engineering processes?  i.e.
a development repo, QA repo, release repo, etc?

Simply “switching to git” and then having one big canonical git repository that we use
exactly the same way as we use svn doesn’t seem to offer many advantages, really.  If the
argument is “but then we could take Github pull requests”, well, we can already do that
with the git mirrors that are there already.

As far as “svn gets really messy for that kind of merge”, I’m not convinced that’s
a tool issue - the fundamental problem is that the qa-refactor branch has diverged from the
main branch for years without a release or much attention from anyone but Peter, blowing away
the “develop on trunk” philosophy, and making “diffs” impossible to evaluate.  No
tool is going to help that. We simply need to either go through it revision by revision, or
just accept it as “the way forward”.  We’ve decided to accept it.

For now, the current “jtsk/trunk” is an unknown factor as much as “jtsk/skunk/qa-refactor-namespace/trunk”.
 I’d suggest renaming “jtsk/trunk” to “jtsk/abandoned” or something, then rename
“jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release from there. 
That’s the path of least bikeshedding.

Cheers,

Greg Trasuk


> On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <pats@acm.org> wrote:
> 
> For moving to Git, see http://www.apache.org/dev/writable-git
> 
> Is the support provided sufficient? How do committers in general feel about moving River
to Git? If it is a good idea, should we do it before Release 3.0? The alternative might be
to rename the current SVN branch and release from there.
> 
> On 9/22/2015 4:31 AM, Bryan Thompson wrote:
>> SVN gets really messy for this sort of thing.  We wound not bringing a
>> project with a large delta back to the trunk because of these issues and
>> just did releases from branches after that.
>> 
>> What kind of support does Apache offer for switching to git?  That might be
>> easier.
>> 
>> Thanks,
>> Bryan
>> 
>> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <pats@acm.org> wrote:
>> 
>>> I think the next thing we need to do to make Release 3.0 a reality is to
>>> merge it into the trunk.
>>> 
>>> If you agree, I would like opinions on the best way to go about it.
>>> Ideally, we will preserve revision history for modules that have moved from
>>> one directory/package to another.
>>> 
>> 


Mime
View raw message