You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2015/09/21 22:49:03 UTC
Release 3.0 merge into trunk
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.
Re: Release 3.0 merge into trunk
Posted by Bryan Thompson <br...@systap.com>.
+1 on moving to git.
+1 on doing this before a 3.0 release if we want to maintain history from
the trunk.
----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
bryan@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io
Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs. Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.
CONFIDENTIALITY NOTICE: This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.
On Tue, Sep 22, 2015 at 9:40 AM, Patricia Shanahan <pa...@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 <pa...@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.
>>>
>>>
>>
Re: Release 3.0 merge into trunk
Posted by Dennis Reedy <de...@gmail.com>.
> On Sep 22, 2015, at 1023AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> 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.
>
In agreement with you Greg. I’m all for moving to Git, and as you point out there are questions involved with doing that. Lets not get distracted (love the bikeshedding comment!). FWIW, we could also just create river/trunk (as opposed to jtsk/trunk) and move jtsk/skunk/qa-refactor-namespace/trunk there.
Regards
Dennis
Re: Release 3.0 merge into trunk
Posted by Greg Trasuk <tr...@stratuscom.com>.
Just to be clear, I agree with Pat here - stay with svn for the initial 3.0 release. If someone’s up for the challenge, try to merge qa-refactor-namespace into trunk. Alternately, just go ahead and replace trunk with qa-refactor-namespace, as I described below.
Greg Trasuk
> On Sep 22, 2015, at 10:52 AM, Patricia Shanahan <pa...@acm.org> wrote:
>
> One concern I have with moving to Git before Release 3.0 is the tension between really thinking through the Git move and getting 3.0 out quickly.
>
> On 9/22/2015 7:23 AM, Greg Trasuk wrote:
>> 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 <pa...@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 <pa...@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.
>>>>>
>>>>
>>
Re: Release 3.0 merge into trunk
Posted by Patricia Shanahan <pa...@acm.org>.
One concern I have with moving to Git before Release 3.0 is the tension
between really thinking through the Git move and getting 3.0 out quickly.
On 9/22/2015 7:23 AM, Greg Trasuk wrote:
> 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 <pa...@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 <pa...@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.
>>>>
>>>
>
Re: Release 3.0 merge into trunk
Posted by Greg Trasuk <tr...@stratuscom.com>.
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 <pa...@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 <pa...@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.
>>>
>>
Re: Release 3.0 merge into trunk
Posted by Patricia Shanahan <pa...@acm.org>.
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 <pa...@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.
>>
>
Re: Release 3.0 merge into trunk
Posted by Dawid Loubser <da...@travellinck.com>.
I concur, all my work, and clients, have moved to git for the very same
reason.
Dawid
On 22/09/2015 13:31, 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 <pa...@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.
>>
Re: Release 3.0 merge into trunk
Posted by Bryan Thompson <br...@systap.com>.
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 <pa...@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.
>