You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2015/10/19 18:50:15 UTC
Branching after 3.0.2-incubating
I believe that one or two discussions have been raised so far on this list
about how we would proceed with release planning and branching once
3.0.2-incubating was released. Here's the link to the most recent one:
http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
Anyway, the short of it is that once 3.0.2 is officially released, we will
stop development on the 3.0.x line of code and thus not commit anything
else to the tp30 branch. Therefore all work for the time being should find
its way to the master branch until we release 3.1.0. If there is a bug in
the 3.0.x line of code, we should look to fix it in 3.1.x (master).
Thanks,
Stephen
Re: Branching after 3.0.2-incubating
Posted by Jason Plurad <pl...@gmail.com>.
Makes sense to me. I just wanted to clear up publicly whether or not a vote
was appropriate/necessary to make the community decision-making process
visible in the spirit of the Apache Way. As you mentioned, this was covered
before adequately here
<http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg%40mail.gmail.com%3E>
(and apparently I just need to monitor this list more closely!).
Thanks, Stephen, and nice job on managing the 3.0.2 release!
On Mon, Oct 19, 2015 at 5:21 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> The position I've been trying to express with this is that active
> development should occur on the 3.1.x line of code. I would say that in the
> event that we turned up a bug that:
>
> 1. Left the system abend AND
> 2. Has no workaround
>
> then we would want to discuss patching 3.0.x here on the list and releasing
> a 3.0.3. I would not be in favor of leaving providers (and their users)
> high and dry on the 3.0.x line of code and that's precisely what that type
> of bug would do.
>
> As for your example, on moving from 3.0.x to 3.1.x, I see the scenario you
> were establishing and perhaps it was for example, but I can't imagine many
> providers not taking the bump to 3.1.x. It's fairly non-invasive and the
> pains generally fall to providers who implemented stuff on hadoop-gremlin
> and/or who have a dependence on hadoop 1.x (I don't believe there are many
> of those). Plus, based on community feedback from our VOTE, users and
> providers alike are eagerly awaiting hadoop 2.x infrastructure, so adoption
> should be fast.
>
> Does that get you feeling more warm and fuzzy about this direction? :)
>
>
>
>
>
> On Mon, Oct 19, 2015 at 4:33 PM, Jason Plurad <pl...@gmail.com> wrote:
>
> > From my personal perspective, I'm happy with moving on to 3.1.
> >
> > I was just thinking from the perspective of graph system providers, like
> > Neo4j. Are they planning to adopt TinkerPop 3.1 when it becomes
> available?
> > What would they do if they find a find a bug in TinkerPop 3.0.0 if
> there's
> > no longer a community-supported 3.0.x branch? I guess they would have to
> > fork it.
> >
> >
> > On Mon, Oct 19, 2015 at 2:46 PM, Stephen Mallette <sp...@gmail.com>
> > wrote:
> >
> > > Well - here's what I saw from my perspective. I post a suggested
> course
> > of
> > > action for future releases weeks before those actions would take
> > effect. I
> > > get a pair or +1s on my post from two committers. No other discussion
> > > occurs and there are no dissenters. I would have thrown up a VOTE if
> > there
> > > had been dissent in the approach and or comments that didn't make the
> > path
> > > forward clear. I don't see the point of this flow:
> > >
> > > 1. discuss an idea
> > > 2. Positive feedback from the community
> > > 3. have a vote
> > >
> > > It seems like we need vote when there is dissension in the
> discussion. I
> > > would say that at step 2 we might want to be careful of no feedback
> from
> > > the community. In that case, we might want some caution and perhaps
> the
> > > originator bumps the thread and says "if no one objects within three
> > days,
> > > I'll assume lazy consensus and move forward". ???
> > >
> > >
> > >
> > > On Mon, Oct 19, 2015 at 2:22 PM, Jason Plurad <pl...@gmail.com>
> wrote:
> > >
> > > > "we will stop development on the 3.0.x line of code and thus not
> commit
> > > > anything
> > > > else to the tp30 branch."
> > > >
> > > > Isn't this something we should have a documented vote on?
> > > >
> > > > On Mon, Oct 19, 2015 at 12:50 PM, Stephen Mallette <
> > spmallette@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I believe that one or two discussions have been raised so far on
> this
> > > > list
> > > > > about how we would proceed with release planning and branching once
> > > > > 3.0.2-incubating was released. Here's the link to the most recent
> > one:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
> > > > >
> > > > > Anyway, the short of it is that once 3.0.2 is officially released,
> we
> > > > will
> > > > > stop development on the 3.0.x line of code and thus not commit
> > anything
> > > > > else to the tp30 branch. Therefore all work for the time being
> > should
> > > > find
> > > > > its way to the master branch until we release 3.1.0. If there is a
> > bug
> > > > in
> > > > > the 3.0.x line of code, we should look to fix it in 3.1.x (master).
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Stephen
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Have a good one,
> > > > Jason
> > > >
> > >
> >
> >
> >
> > --
> > Have a good one,
> > Jason
> >
>
--
Have a good one,
Jason
Re: Branching after 3.0.2-incubating
Posted by Stephen Mallette <sp...@gmail.com>.
The position I've been trying to express with this is that active
development should occur on the 3.1.x line of code. I would say that in the
event that we turned up a bug that:
1. Left the system abend AND
2. Has no workaround
then we would want to discuss patching 3.0.x here on the list and releasing
a 3.0.3. I would not be in favor of leaving providers (and their users)
high and dry on the 3.0.x line of code and that's precisely what that type
of bug would do.
As for your example, on moving from 3.0.x to 3.1.x, I see the scenario you
were establishing and perhaps it was for example, but I can't imagine many
providers not taking the bump to 3.1.x. It's fairly non-invasive and the
pains generally fall to providers who implemented stuff on hadoop-gremlin
and/or who have a dependence on hadoop 1.x (I don't believe there are many
of those). Plus, based on community feedback from our VOTE, users and
providers alike are eagerly awaiting hadoop 2.x infrastructure, so adoption
should be fast.
Does that get you feeling more warm and fuzzy about this direction? :)
On Mon, Oct 19, 2015 at 4:33 PM, Jason Plurad <pl...@gmail.com> wrote:
> From my personal perspective, I'm happy with moving on to 3.1.
>
> I was just thinking from the perspective of graph system providers, like
> Neo4j. Are they planning to adopt TinkerPop 3.1 when it becomes available?
> What would they do if they find a find a bug in TinkerPop 3.0.0 if there's
> no longer a community-supported 3.0.x branch? I guess they would have to
> fork it.
>
>
> On Mon, Oct 19, 2015 at 2:46 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > Well - here's what I saw from my perspective. I post a suggested course
> of
> > action for future releases weeks before those actions would take
> effect. I
> > get a pair or +1s on my post from two committers. No other discussion
> > occurs and there are no dissenters. I would have thrown up a VOTE if
> there
> > had been dissent in the approach and or comments that didn't make the
> path
> > forward clear. I don't see the point of this flow:
> >
> > 1. discuss an idea
> > 2. Positive feedback from the community
> > 3. have a vote
> >
> > It seems like we need vote when there is dissension in the discussion. I
> > would say that at step 2 we might want to be careful of no feedback from
> > the community. In that case, we might want some caution and perhaps the
> > originator bumps the thread and says "if no one objects within three
> days,
> > I'll assume lazy consensus and move forward". ???
> >
> >
> >
> > On Mon, Oct 19, 2015 at 2:22 PM, Jason Plurad <pl...@gmail.com> wrote:
> >
> > > "we will stop development on the 3.0.x line of code and thus not commit
> > > anything
> > > else to the tp30 branch."
> > >
> > > Isn't this something we should have a documented vote on?
> > >
> > > On Mon, Oct 19, 2015 at 12:50 PM, Stephen Mallette <
> spmallette@gmail.com
> > >
> > > wrote:
> > >
> > > > I believe that one or two discussions have been raised so far on this
> > > list
> > > > about how we would proceed with release planning and branching once
> > > > 3.0.2-incubating was released. Here's the link to the most recent
> one:
> > > >
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
> > > >
> > > > Anyway, the short of it is that once 3.0.2 is officially released, we
> > > will
> > > > stop development on the 3.0.x line of code and thus not commit
> anything
> > > > else to the tp30 branch. Therefore all work for the time being
> should
> > > find
> > > > its way to the master branch until we release 3.1.0. If there is a
> bug
> > > in
> > > > the 3.0.x line of code, we should look to fix it in 3.1.x (master).
> > > >
> > > > Thanks,
> > > >
> > > > Stephen
> > > >
> > >
> > >
> > >
> > > --
> > > Have a good one,
> > > Jason
> > >
> >
>
>
>
> --
> Have a good one,
> Jason
>
Re: Branching after 3.0.2-incubating
Posted by Jason Plurad <pl...@gmail.com>.
>From my personal perspective, I'm happy with moving on to 3.1.
I was just thinking from the perspective of graph system providers, like
Neo4j. Are they planning to adopt TinkerPop 3.1 when it becomes available?
What would they do if they find a find a bug in TinkerPop 3.0.0 if there's
no longer a community-supported 3.0.x branch? I guess they would have to
fork it.
On Mon, Oct 19, 2015 at 2:46 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> Well - here's what I saw from my perspective. I post a suggested course of
> action for future releases weeks before those actions would take effect. I
> get a pair or +1s on my post from two committers. No other discussion
> occurs and there are no dissenters. I would have thrown up a VOTE if there
> had been dissent in the approach and or comments that didn't make the path
> forward clear. I don't see the point of this flow:
>
> 1. discuss an idea
> 2. Positive feedback from the community
> 3. have a vote
>
> It seems like we need vote when there is dissension in the discussion. I
> would say that at step 2 we might want to be careful of no feedback from
> the community. In that case, we might want some caution and perhaps the
> originator bumps the thread and says "if no one objects within three days,
> I'll assume lazy consensus and move forward". ???
>
>
>
> On Mon, Oct 19, 2015 at 2:22 PM, Jason Plurad <pl...@gmail.com> wrote:
>
> > "we will stop development on the 3.0.x line of code and thus not commit
> > anything
> > else to the tp30 branch."
> >
> > Isn't this something we should have a documented vote on?
> >
> > On Mon, Oct 19, 2015 at 12:50 PM, Stephen Mallette <spmallette@gmail.com
> >
> > wrote:
> >
> > > I believe that one or two discussions have been raised so far on this
> > list
> > > about how we would proceed with release planning and branching once
> > > 3.0.2-incubating was released. Here's the link to the most recent one:
> > >
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
> > >
> > > Anyway, the short of it is that once 3.0.2 is officially released, we
> > will
> > > stop development on the 3.0.x line of code and thus not commit anything
> > > else to the tp30 branch. Therefore all work for the time being should
> > find
> > > its way to the master branch until we release 3.1.0. If there is a bug
> > in
> > > the 3.0.x line of code, we should look to fix it in 3.1.x (master).
> > >
> > > Thanks,
> > >
> > > Stephen
> > >
> >
> >
> >
> > --
> > Have a good one,
> > Jason
> >
>
--
Have a good one,
Jason
Re: Branching after 3.0.2-incubating
Posted by Stephen Mallette <sp...@gmail.com>.
Well - here's what I saw from my perspective. I post a suggested course of
action for future releases weeks before those actions would take effect. I
get a pair or +1s on my post from two committers. No other discussion
occurs and there are no dissenters. I would have thrown up a VOTE if there
had been dissent in the approach and or comments that didn't make the path
forward clear. I don't see the point of this flow:
1. discuss an idea
2. Positive feedback from the community
3. have a vote
It seems like we need vote when there is dissension in the discussion. I
would say that at step 2 we might want to be careful of no feedback from
the community. In that case, we might want some caution and perhaps the
originator bumps the thread and says "if no one objects within three days,
I'll assume lazy consensus and move forward". ???
On Mon, Oct 19, 2015 at 2:22 PM, Jason Plurad <pl...@gmail.com> wrote:
> "we will stop development on the 3.0.x line of code and thus not commit
> anything
> else to the tp30 branch."
>
> Isn't this something we should have a documented vote on?
>
> On Mon, Oct 19, 2015 at 12:50 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > I believe that one or two discussions have been raised so far on this
> list
> > about how we would proceed with release planning and branching once
> > 3.0.2-incubating was released. Here's the link to the most recent one:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
> >
> > Anyway, the short of it is that once 3.0.2 is officially released, we
> will
> > stop development on the 3.0.x line of code and thus not commit anything
> > else to the tp30 branch. Therefore all work for the time being should
> find
> > its way to the master branch until we release 3.1.0. If there is a bug
> in
> > the 3.0.x line of code, we should look to fix it in 3.1.x (master).
> >
> > Thanks,
> >
> > Stephen
> >
>
>
>
> --
> Have a good one,
> Jason
>
Re: Branching after 3.0.2-incubating
Posted by Jason Plurad <pl...@gmail.com>.
"we will stop development on the 3.0.x line of code and thus not commit
anything
else to the tp30 branch."
Isn't this something we should have a documented vote on?
On Mon, Oct 19, 2015 at 12:50 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> I believe that one or two discussions have been raised so far on this list
> about how we would proceed with release planning and branching once
> 3.0.2-incubating was released. Here's the link to the most recent one:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/201509.mbox/%3CCAA-H438mJCWgZD5VHbcVw9NVDUynPX2poLFcGOv23g6bYKcCqg@mail.gmail.com%3E
>
> Anyway, the short of it is that once 3.0.2 is officially released, we will
> stop development on the 3.0.x line of code and thus not commit anything
> else to the tp30 branch. Therefore all work for the time being should find
> its way to the master branch until we release 3.1.0. If there is a bug in
> the 3.0.x line of code, we should look to fix it in 3.1.x (master).
>
> Thanks,
>
> Stephen
>
--
Have a good one,
Jason