You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Marko Rodriguez <ok...@gmail.com> on 2015/09/02 15:27:14 UTC
Contributing to TinkerPop -- Please do not rush your work.
Hello,
If you are going to commit work to a branch that is about to be released, either do it right or save it for another release. We can not have last minute features causing problems for our committers and our users.
In particular, as an example, I'm calling out BulkLoaderVertexProgram. Why was including this feature bad for 3.0.1?
1. Work was being done on it up to the last minute where our release was delayed a day because of it.
2. There are no docs written about the feature and thus, the work is NOT complete (docs are the other 1/2 of the solution).
3. The rush to get the feature in caused sloppy hacks -- ComputerVerificationStrategy exception addition, configuration keys that don't conform to standard practices, ??.
4. It required the time of other committers to focus on this as opposed to doing their work thus, effecting their attention to other details of the release.
5. Stephen and I are now having to spend time figuring out how to do the 3.0.1 release --- time and focus wasted on pointless inanities.
If you are not going to do things right, then please save your work for another release when you have the time to think, document, and test things thoroughly. In particular to BLVP, there is no reason to slip this feature in to 3.0.1. Why not save it for 3.1.0?
In short, please don't procrastinate (though I think BLVP was more of a rush issue) and don't make hasty decisions to "just get things working."
Give a hoot, don't pollute.
Thank you,
Marko.
http://markorodriguez.com
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Stephen Mallette <sp...@gmail.com>.
> Who's responsible for the HA implementation? Michael Hunger?
Well, Michael Hunger would be the person to talk to about it. I pinged him
on it last week but didn't get a response yet. I'm not so sure he has to
do it specifically though - if he's busy we might be able to do it. He
would have to do the actual release of a stable version though. Let's try
to settle 3.0.1 and then we can talk more about HA support.
> What's the deadline for 3.0.2?
No plan yet, but I suspect it would be partially driven by
the availability of this feature.
On Wed, Sep 2, 2015 at 11:23 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> >
> > I guess the real solution here would be to get Neo4j HA into the
> mix........maybe
> > that is doable for 3.0.2?
>
>
> Who's responsible for the HA implementation? Michael Hunger? What's the
> deadline for 3.0.2?
>
> I will try the supportsPersistence() hack*** locally, can't promise that it
> will work though.
>
> ** I don't see that as a long term solution*
>
>
>
> On Wed, Sep 2, 2015 at 5:12 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > Maybe you can change that line to supportsPersistence() then TinkerGraph
> > would be "disabled" but Neo4jGraph would "work" as long as the user knew
> to
> > not try to parallel load it. Would that make sense for the immediate
> term?
> >
> >
> > I guess the real solution here would be to get Neo4j HA into the
> > mix........maybe that is doable for 3.0.2?
> >
> > On Wed, Sep 2, 2015 at 10:48 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> >
> > > I would still have to remove the "allow concurrent connections" check
> > > <
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L175
> > > >.
> > > BulkLoaderVertexProgram does not know if it's started single-threaded
> or
> > > with multi-threaded or even in a distributed environment (multiple
> JVMs).
> > >
> > > And again regarding TinkerGraph: You won't have access to that graph.
> It
> > > doesn't matter if it's Spark or Giraph. You pass a writeGraph
> > configuration
> > > file for TinkerGraph, BLVP would use that file to create
> > > <
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L172
> > > >
> > > a TinkerGraph instance, load
> > > <
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L209
> > > >
> > > the data and close
> > > <
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L135
> > > >
> > > the graph. And then what? The next one who sees the graph is the GC.
> The
> > > only thing that could work (with a few hacks and preconditions) would
> be
> > > Neo4j. A lot of other Graph DBs (e.g. Titan, OrientDB, etc.) would
> > probably
> > > work out of the box, but we don't have those in our TinkerPop
> dependency
> > > list, hence we can't / shouldn't use them in the docs.
> > >
> > > On Wed, Sep 2, 2015 at 4:26 PM, Stephen Mallette <spmallette@gmail.com
> >
> > > wrote:
> > >
> > > > Well - Neo4j would persist - maybe single thread that? what would
> that
> > > > look like? would that be helpful to users to at least demonstrate
> how
> > it
> > > > would work?
> > > >
> > > > On Wed, Sep 2, 2015 at 10:12 AM, Daniel Kuppitz <me...@gremlin.guru>
> > wrote:
> > > >
> > > > > No, that wouldn't make much sense, since TinkerGraph is an
> in-memory
> > > > > implementation. Even if I would remove the concurrent connection
> > > support
> > > > > check, Spark/Giraph would start the process in an isolated JVM and
> > the
> > > > > graph would be lost once it's done.
> > > > >
> > > > >
> > > > > On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <
> > spmallette@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Since BLVP isn't documented yet, we really can't promote it as a
> > > > feature.
> > > > > > I'm going to take this approach for release of 3.0.1:
> > > > > >
> > > > > > 1. Re-open the BLVP issue in JIRA
> > > > > > 2. Remove the 3.0.1 tag in the Fix Version (that will remove it
> > from
> > > > the
> > > > > > release notes).
> > > > > > 3. We push BLVP forward to 3.0.2 and complete docs and other
> fixes
> > at
> > > > > that
> > > > > > point.
> > > > > >
> > > > > > Daniel, I know there's some issue with our core implementations
> not
> > > > > > supporting parallel loading, but can the docs be written using
> > > > > TinkerGraph
> > > > > > as an example (even if that's just a single threaded process to
> do
> > > it)?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <
> > > okrammarko@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > If you are going to commit work to a branch that is about to be
> > > > > released,
> > > > > > > either do it right or save it for another release. We can not
> > have
> > > > last
> > > > > > > minute features causing problems for our committers and our
> > users.
> > > > > > >
> > > > > > > In particular, as an example, I'm calling out
> > > > BulkLoaderVertexProgram.
> > > > > > Why
> > > > > > > was including this feature bad for 3.0.1?
> > > > > > >
> > > > > > > 1. Work was being done on it up to the last minute
> where
> > > our
> > > > > > > release was delayed a day because of it.
> > > > > > > 2. There are no docs written about the feature and
> thus,
> > > the
> > > > > work
> > > > > > > is NOT complete (docs are the other 1/2 of the solution).
> > > > > > > 3. The rush to get the feature in caused sloppy hacks
> --
> > > > > > > ComputerVerificationStrategy exception addition, configuration
> > keys
> > > > > that
> > > > > > > don't conform to standard practices, ??.
> > > > > > > 4. It required the time of other committers to focus on
> > > this
> > > > as
> > > > > > > opposed to doing their work thus, effecting their attention to
> > > other
> > > > > > > details of the release.
> > > > > > > 5. Stephen and I are now having to spend time figuring
> > out
> > > > how
> > > > > to
> > > > > > > do the 3.0.1 release --- time and focus wasted on pointless
> > > > inanities.
> > > > > > >
> > > > > > > If you are not going to do things right, then please save your
> > work
> > > > for
> > > > > > > another release when you have the time to think, document, and
> > test
> > > > > > things
> > > > > > > thoroughly. In particular to BLVP, there is no reason to slip
> > this
> > > > > > feature
> > > > > > > in to 3.0.1. Why not save it for 3.1.0?
> > > > > > >
> > > > > > > In short, please don't procrastinate (though I think BLVP was
> > more
> > > > of a
> > > > > > > rush issue) and don't make hasty decisions to "just get things
> > > > > working."
> > > > > > >
> > > > > > > Give a hoot, don't pollute.
> > > > > > >
> > > > > > > Thank you,
> > > > > > > Marko.
> > > > > > >
> > > > > > > http://markorodriguez.com
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Daniel Kuppitz <me...@gremlin.guru>.
>
> I guess the real solution here would be to get Neo4j HA into the mix........maybe
> that is doable for 3.0.2?
Who's responsible for the HA implementation? Michael Hunger? What's the
deadline for 3.0.2?
I will try the supportsPersistence() hack*** locally, can't promise that it
will work though.
** I don't see that as a long term solution*
On Wed, Sep 2, 2015 at 5:12 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> Maybe you can change that line to supportsPersistence() then TinkerGraph
> would be "disabled" but Neo4jGraph would "work" as long as the user knew to
> not try to parallel load it. Would that make sense for the immediate term?
>
>
> I guess the real solution here would be to get Neo4j HA into the
> mix........maybe that is doable for 3.0.2?
>
> On Wed, Sep 2, 2015 at 10:48 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
>
> > I would still have to remove the "allow concurrent connections" check
> > <
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L175
> > >.
> > BulkLoaderVertexProgram does not know if it's started single-threaded or
> > with multi-threaded or even in a distributed environment (multiple JVMs).
> >
> > And again regarding TinkerGraph: You won't have access to that graph. It
> > doesn't matter if it's Spark or Giraph. You pass a writeGraph
> configuration
> > file for TinkerGraph, BLVP would use that file to create
> > <
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L172
> > >
> > a TinkerGraph instance, load
> > <
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L209
> > >
> > the data and close
> > <
> >
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L135
> > >
> > the graph. And then what? The next one who sees the graph is the GC. The
> > only thing that could work (with a few hacks and preconditions) would be
> > Neo4j. A lot of other Graph DBs (e.g. Titan, OrientDB, etc.) would
> probably
> > work out of the box, but we don't have those in our TinkerPop dependency
> > list, hence we can't / shouldn't use them in the docs.
> >
> > On Wed, Sep 2, 2015 at 4:26 PM, Stephen Mallette <sp...@gmail.com>
> > wrote:
> >
> > > Well - Neo4j would persist - maybe single thread that? what would that
> > > look like? would that be helpful to users to at least demonstrate how
> it
> > > would work?
> > >
> > > On Wed, Sep 2, 2015 at 10:12 AM, Daniel Kuppitz <me...@gremlin.guru>
> wrote:
> > >
> > > > No, that wouldn't make much sense, since TinkerGraph is an in-memory
> > > > implementation. Even if I would remove the concurrent connection
> > support
> > > > check, Spark/Giraph would start the process in an isolated JVM and
> the
> > > > graph would be lost once it's done.
> > > >
> > > >
> > > > On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <
> spmallette@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Since BLVP isn't documented yet, we really can't promote it as a
> > > feature.
> > > > > I'm going to take this approach for release of 3.0.1:
> > > > >
> > > > > 1. Re-open the BLVP issue in JIRA
> > > > > 2. Remove the 3.0.1 tag in the Fix Version (that will remove it
> from
> > > the
> > > > > release notes).
> > > > > 3. We push BLVP forward to 3.0.2 and complete docs and other fixes
> at
> > > > that
> > > > > point.
> > > > >
> > > > > Daniel, I know there's some issue with our core implementations not
> > > > > supporting parallel loading, but can the docs be written using
> > > > TinkerGraph
> > > > > as an example (even if that's just a single threaded process to do
> > it)?
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <
> > okrammarko@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > If you are going to commit work to a branch that is about to be
> > > > released,
> > > > > > either do it right or save it for another release. We can not
> have
> > > last
> > > > > > minute features causing problems for our committers and our
> users.
> > > > > >
> > > > > > In particular, as an example, I'm calling out
> > > BulkLoaderVertexProgram.
> > > > > Why
> > > > > > was including this feature bad for 3.0.1?
> > > > > >
> > > > > > 1. Work was being done on it up to the last minute where
> > our
> > > > > > release was delayed a day because of it.
> > > > > > 2. There are no docs written about the feature and thus,
> > the
> > > > work
> > > > > > is NOT complete (docs are the other 1/2 of the solution).
> > > > > > 3. The rush to get the feature in caused sloppy hacks --
> > > > > > ComputerVerificationStrategy exception addition, configuration
> keys
> > > > that
> > > > > > don't conform to standard practices, ??.
> > > > > > 4. It required the time of other committers to focus on
> > this
> > > as
> > > > > > opposed to doing their work thus, effecting their attention to
> > other
> > > > > > details of the release.
> > > > > > 5. Stephen and I are now having to spend time figuring
> out
> > > how
> > > > to
> > > > > > do the 3.0.1 release --- time and focus wasted on pointless
> > > inanities.
> > > > > >
> > > > > > If you are not going to do things right, then please save your
> work
> > > for
> > > > > > another release when you have the time to think, document, and
> test
> > > > > things
> > > > > > thoroughly. In particular to BLVP, there is no reason to slip
> this
> > > > > feature
> > > > > > in to 3.0.1. Why not save it for 3.1.0?
> > > > > >
> > > > > > In short, please don't procrastinate (though I think BLVP was
> more
> > > of a
> > > > > > rush issue) and don't make hasty decisions to "just get things
> > > > working."
> > > > > >
> > > > > > Give a hoot, don't pollute.
> > > > > >
> > > > > > Thank you,
> > > > > > Marko.
> > > > > >
> > > > > > http://markorodriguez.com
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Stephen Mallette <sp...@gmail.com>.
Maybe you can change that line to supportsPersistence() then TinkerGraph
would be "disabled" but Neo4jGraph would "work" as long as the user knew to
not try to parallel load it. Would that make sense for the immediate term?
I guess the real solution here would be to get Neo4j HA into the
mix........maybe that is doable for 3.0.2?
On Wed, Sep 2, 2015 at 10:48 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> I would still have to remove the "allow concurrent connections" check
> <
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L175
> >.
> BulkLoaderVertexProgram does not know if it's started single-threaded or
> with multi-threaded or even in a distributed environment (multiple JVMs).
>
> And again regarding TinkerGraph: You won't have access to that graph. It
> doesn't matter if it's Spark or Giraph. You pass a writeGraph configuration
> file for TinkerGraph, BLVP would use that file to create
> <
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L172
> >
> a TinkerGraph instance, load
> <
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L209
> >
> the data and close
> <
> https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L135
> >
> the graph. And then what? The next one who sees the graph is the GC. The
> only thing that could work (with a few hacks and preconditions) would be
> Neo4j. A lot of other Graph DBs (e.g. Titan, OrientDB, etc.) would probably
> work out of the box, but we don't have those in our TinkerPop dependency
> list, hence we can't / shouldn't use them in the docs.
>
> On Wed, Sep 2, 2015 at 4:26 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > Well - Neo4j would persist - maybe single thread that? what would that
> > look like? would that be helpful to users to at least demonstrate how it
> > would work?
> >
> > On Wed, Sep 2, 2015 at 10:12 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> >
> > > No, that wouldn't make much sense, since TinkerGraph is an in-memory
> > > implementation. Even if I would remove the concurrent connection
> support
> > > check, Spark/Giraph would start the process in an isolated JVM and the
> > > graph would be lost once it's done.
> > >
> > >
> > > On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <spmallette@gmail.com
> >
> > > wrote:
> > >
> > > > Since BLVP isn't documented yet, we really can't promote it as a
> > feature.
> > > > I'm going to take this approach for release of 3.0.1:
> > > >
> > > > 1. Re-open the BLVP issue in JIRA
> > > > 2. Remove the 3.0.1 tag in the Fix Version (that will remove it from
> > the
> > > > release notes).
> > > > 3. We push BLVP forward to 3.0.2 and complete docs and other fixes at
> > > that
> > > > point.
> > > >
> > > > Daniel, I know there's some issue with our core implementations not
> > > > supporting parallel loading, but can the docs be written using
> > > TinkerGraph
> > > > as an example (even if that's just a single threaded process to do
> it)?
> > > >
> > > >
> > > >
> > > > On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <
> okrammarko@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > If you are going to commit work to a branch that is about to be
> > > released,
> > > > > either do it right or save it for another release. We can not have
> > last
> > > > > minute features causing problems for our committers and our users.
> > > > >
> > > > > In particular, as an example, I'm calling out
> > BulkLoaderVertexProgram.
> > > > Why
> > > > > was including this feature bad for 3.0.1?
> > > > >
> > > > > 1. Work was being done on it up to the last minute where
> our
> > > > > release was delayed a day because of it.
> > > > > 2. There are no docs written about the feature and thus,
> the
> > > work
> > > > > is NOT complete (docs are the other 1/2 of the solution).
> > > > > 3. The rush to get the feature in caused sloppy hacks --
> > > > > ComputerVerificationStrategy exception addition, configuration keys
> > > that
> > > > > don't conform to standard practices, ??.
> > > > > 4. It required the time of other committers to focus on
> this
> > as
> > > > > opposed to doing their work thus, effecting their attention to
> other
> > > > > details of the release.
> > > > > 5. Stephen and I are now having to spend time figuring out
> > how
> > > to
> > > > > do the 3.0.1 release --- time and focus wasted on pointless
> > inanities.
> > > > >
> > > > > If you are not going to do things right, then please save your work
> > for
> > > > > another release when you have the time to think, document, and test
> > > > things
> > > > > thoroughly. In particular to BLVP, there is no reason to slip this
> > > > feature
> > > > > in to 3.0.1. Why not save it for 3.1.0?
> > > > >
> > > > > In short, please don't procrastinate (though I think BLVP was more
> > of a
> > > > > rush issue) and don't make hasty decisions to "just get things
> > > working."
> > > > >
> > > > > Give a hoot, don't pollute.
> > > > >
> > > > > Thank you,
> > > > > Marko.
> > > > >
> > > > > http://markorodriguez.com
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Daniel Kuppitz <me...@gremlin.guru>.
I would still have to remove the "allow concurrent connections" check
<https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L175>.
BulkLoaderVertexProgram does not know if it's started single-threaded or
with multi-threaded or even in a distributed environment (multiple JVMs).
And again regarding TinkerGraph: You won't have access to that graph. It
doesn't matter if it's Spark or Giraph. You pass a writeGraph configuration
file for TinkerGraph, BLVP would use that file to create
<https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L172>
a TinkerGraph instance, load
<https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L209>
the data and close
<https://github.com/apache/incubator-tinkerpop/blob/tp30/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/bulkloading/BulkLoaderVertexProgram.java#L135>
the graph. And then what? The next one who sees the graph is the GC. The
only thing that could work (with a few hacks and preconditions) would be
Neo4j. A lot of other Graph DBs (e.g. Titan, OrientDB, etc.) would probably
work out of the box, but we don't have those in our TinkerPop dependency
list, hence we can't / shouldn't use them in the docs.
On Wed, Sep 2, 2015 at 4:26 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> Well - Neo4j would persist - maybe single thread that? what would that
> look like? would that be helpful to users to at least demonstrate how it
> would work?
>
> On Wed, Sep 2, 2015 at 10:12 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
>
> > No, that wouldn't make much sense, since TinkerGraph is an in-memory
> > implementation. Even if I would remove the concurrent connection support
> > check, Spark/Giraph would start the process in an isolated JVM and the
> > graph would be lost once it's done.
> >
> >
> > On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <sp...@gmail.com>
> > wrote:
> >
> > > Since BLVP isn't documented yet, we really can't promote it as a
> feature.
> > > I'm going to take this approach for release of 3.0.1:
> > >
> > > 1. Re-open the BLVP issue in JIRA
> > > 2. Remove the 3.0.1 tag in the Fix Version (that will remove it from
> the
> > > release notes).
> > > 3. We push BLVP forward to 3.0.2 and complete docs and other fixes at
> > that
> > > point.
> > >
> > > Daniel, I know there's some issue with our core implementations not
> > > supporting parallel loading, but can the docs be written using
> > TinkerGraph
> > > as an example (even if that's just a single threaded process to do it)?
> > >
> > >
> > >
> > > On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <ok...@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > If you are going to commit work to a branch that is about to be
> > released,
> > > > either do it right or save it for another release. We can not have
> last
> > > > minute features causing problems for our committers and our users.
> > > >
> > > > In particular, as an example, I'm calling out
> BulkLoaderVertexProgram.
> > > Why
> > > > was including this feature bad for 3.0.1?
> > > >
> > > > 1. Work was being done on it up to the last minute where our
> > > > release was delayed a day because of it.
> > > > 2. There are no docs written about the feature and thus, the
> > work
> > > > is NOT complete (docs are the other 1/2 of the solution).
> > > > 3. The rush to get the feature in caused sloppy hacks --
> > > > ComputerVerificationStrategy exception addition, configuration keys
> > that
> > > > don't conform to standard practices, ??.
> > > > 4. It required the time of other committers to focus on this
> as
> > > > opposed to doing their work thus, effecting their attention to other
> > > > details of the release.
> > > > 5. Stephen and I are now having to spend time figuring out
> how
> > to
> > > > do the 3.0.1 release --- time and focus wasted on pointless
> inanities.
> > > >
> > > > If you are not going to do things right, then please save your work
> for
> > > > another release when you have the time to think, document, and test
> > > things
> > > > thoroughly. In particular to BLVP, there is no reason to slip this
> > > feature
> > > > in to 3.0.1. Why not save it for 3.1.0?
> > > >
> > > > In short, please don't procrastinate (though I think BLVP was more
> of a
> > > > rush issue) and don't make hasty decisions to "just get things
> > working."
> > > >
> > > > Give a hoot, don't pollute.
> > > >
> > > > Thank you,
> > > > Marko.
> > > >
> > > > http://markorodriguez.com
> > > >
> > > >
> > >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Stephen Mallette <sp...@gmail.com>.
Well - Neo4j would persist - maybe single thread that? what would that
look like? would that be helpful to users to at least demonstrate how it
would work?
On Wed, Sep 2, 2015 at 10:12 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> No, that wouldn't make much sense, since TinkerGraph is an in-memory
> implementation. Even if I would remove the concurrent connection support
> check, Spark/Giraph would start the process in an isolated JVM and the
> graph would be lost once it's done.
>
>
> On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > Since BLVP isn't documented yet, we really can't promote it as a feature.
> > I'm going to take this approach for release of 3.0.1:
> >
> > 1. Re-open the BLVP issue in JIRA
> > 2. Remove the 3.0.1 tag in the Fix Version (that will remove it from the
> > release notes).
> > 3. We push BLVP forward to 3.0.2 and complete docs and other fixes at
> that
> > point.
> >
> > Daniel, I know there's some issue with our core implementations not
> > supporting parallel loading, but can the docs be written using
> TinkerGraph
> > as an example (even if that's just a single threaded process to do it)?
> >
> >
> >
> > On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <ok...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > If you are going to commit work to a branch that is about to be
> released,
> > > either do it right or save it for another release. We can not have last
> > > minute features causing problems for our committers and our users.
> > >
> > > In particular, as an example, I'm calling out BulkLoaderVertexProgram.
> > Why
> > > was including this feature bad for 3.0.1?
> > >
> > > 1. Work was being done on it up to the last minute where our
> > > release was delayed a day because of it.
> > > 2. There are no docs written about the feature and thus, the
> work
> > > is NOT complete (docs are the other 1/2 of the solution).
> > > 3. The rush to get the feature in caused sloppy hacks --
> > > ComputerVerificationStrategy exception addition, configuration keys
> that
> > > don't conform to standard practices, ??.
> > > 4. It required the time of other committers to focus on this as
> > > opposed to doing their work thus, effecting their attention to other
> > > details of the release.
> > > 5. Stephen and I are now having to spend time figuring out how
> to
> > > do the 3.0.1 release --- time and focus wasted on pointless inanities.
> > >
> > > If you are not going to do things right, then please save your work for
> > > another release when you have the time to think, document, and test
> > things
> > > thoroughly. In particular to BLVP, there is no reason to slip this
> > feature
> > > in to 3.0.1. Why not save it for 3.1.0?
> > >
> > > In short, please don't procrastinate (though I think BLVP was more of a
> > > rush issue) and don't make hasty decisions to "just get things
> working."
> > >
> > > Give a hoot, don't pollute.
> > >
> > > Thank you,
> > > Marko.
> > >
> > > http://markorodriguez.com
> > >
> > >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Marko Rodriguez <ok...@gmail.com>.
Hello,
For the docs on BLVP, can't you just load TinkerGraph (with "modern") into TinkerGraph (empty)? Why does it need Spark/Giraph?
Note that TinkerGraph has ConcurrentHashMap for vertices/edges. I don't know how parallel writes would work, but worth trying.
Marko.
http://markorodriguez.com
On Sep 2, 2015, at 8:12 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> No, that wouldn't make much sense, since TinkerGraph is an in-memory
> implementation. Even if I would remove the concurrent connection support
> check, Spark/Giraph would start the process in an isolated JVM and the
> graph would be lost once it's done.
>
>
> On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
>> Since BLVP isn't documented yet, we really can't promote it as a feature.
>> I'm going to take this approach for release of 3.0.1:
>>
>> 1. Re-open the BLVP issue in JIRA
>> 2. Remove the 3.0.1 tag in the Fix Version (that will remove it from the
>> release notes).
>> 3. We push BLVP forward to 3.0.2 and complete docs and other fixes at that
>> point.
>>
>> Daniel, I know there's some issue with our core implementations not
>> supporting parallel loading, but can the docs be written using TinkerGraph
>> as an example (even if that's just a single threaded process to do it)?
>>
>>
>>
>> On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <ok...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> If you are going to commit work to a branch that is about to be released,
>>> either do it right or save it for another release. We can not have last
>>> minute features causing problems for our committers and our users.
>>>
>>> In particular, as an example, I'm calling out BulkLoaderVertexProgram.
>> Why
>>> was including this feature bad for 3.0.1?
>>>
>>> 1. Work was being done on it up to the last minute where our
>>> release was delayed a day because of it.
>>> 2. There are no docs written about the feature and thus, the work
>>> is NOT complete (docs are the other 1/2 of the solution).
>>> 3. The rush to get the feature in caused sloppy hacks --
>>> ComputerVerificationStrategy exception addition, configuration keys that
>>> don't conform to standard practices, ??.
>>> 4. It required the time of other committers to focus on this as
>>> opposed to doing their work thus, effecting their attention to other
>>> details of the release.
>>> 5. Stephen and I are now having to spend time figuring out how to
>>> do the 3.0.1 release --- time and focus wasted on pointless inanities.
>>>
>>> If you are not going to do things right, then please save your work for
>>> another release when you have the time to think, document, and test
>> things
>>> thoroughly. In particular to BLVP, there is no reason to slip this
>> feature
>>> in to 3.0.1. Why not save it for 3.1.0?
>>>
>>> In short, please don't procrastinate (though I think BLVP was more of a
>>> rush issue) and don't make hasty decisions to "just get things working."
>>>
>>> Give a hoot, don't pollute.
>>>
>>> Thank you,
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>>
>>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Daniel Kuppitz <me...@gremlin.guru>.
No, that wouldn't make much sense, since TinkerGraph is an in-memory
implementation. Even if I would remove the concurrent connection support
check, Spark/Giraph would start the process in an isolated JVM and the
graph would be lost once it's done.
On Wed, Sep 2, 2015 at 4:08 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> Since BLVP isn't documented yet, we really can't promote it as a feature.
> I'm going to take this approach for release of 3.0.1:
>
> 1. Re-open the BLVP issue in JIRA
> 2. Remove the 3.0.1 tag in the Fix Version (that will remove it from the
> release notes).
> 3. We push BLVP forward to 3.0.2 and complete docs and other fixes at that
> point.
>
> Daniel, I know there's some issue with our core implementations not
> supporting parallel loading, but can the docs be written using TinkerGraph
> as an example (even if that's just a single threaded process to do it)?
>
>
>
> On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <ok...@gmail.com>
> wrote:
>
> > Hello,
> >
> > If you are going to commit work to a branch that is about to be released,
> > either do it right or save it for another release. We can not have last
> > minute features causing problems for our committers and our users.
> >
> > In particular, as an example, I'm calling out BulkLoaderVertexProgram.
> Why
> > was including this feature bad for 3.0.1?
> >
> > 1. Work was being done on it up to the last minute where our
> > release was delayed a day because of it.
> > 2. There are no docs written about the feature and thus, the work
> > is NOT complete (docs are the other 1/2 of the solution).
> > 3. The rush to get the feature in caused sloppy hacks --
> > ComputerVerificationStrategy exception addition, configuration keys that
> > don't conform to standard practices, ??.
> > 4. It required the time of other committers to focus on this as
> > opposed to doing their work thus, effecting their attention to other
> > details of the release.
> > 5. Stephen and I are now having to spend time figuring out how to
> > do the 3.0.1 release --- time and focus wasted on pointless inanities.
> >
> > If you are not going to do things right, then please save your work for
> > another release when you have the time to think, document, and test
> things
> > thoroughly. In particular to BLVP, there is no reason to slip this
> feature
> > in to 3.0.1. Why not save it for 3.1.0?
> >
> > In short, please don't procrastinate (though I think BLVP was more of a
> > rush issue) and don't make hasty decisions to "just get things working."
> >
> > Give a hoot, don't pollute.
> >
> > Thank you,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Stephen Mallette <sp...@gmail.com>.
Since BLVP isn't documented yet, we really can't promote it as a feature.
I'm going to take this approach for release of 3.0.1:
1. Re-open the BLVP issue in JIRA
2. Remove the 3.0.1 tag in the Fix Version (that will remove it from the
release notes).
3. We push BLVP forward to 3.0.2 and complete docs and other fixes at that
point.
Daniel, I know there's some issue with our core implementations not
supporting parallel loading, but can the docs be written using TinkerGraph
as an example (even if that's just a single threaded process to do it)?
On Wed, Sep 2, 2015 at 9:27 AM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hello,
>
> If you are going to commit work to a branch that is about to be released,
> either do it right or save it for another release. We can not have last
> minute features causing problems for our committers and our users.
>
> In particular, as an example, I'm calling out BulkLoaderVertexProgram. Why
> was including this feature bad for 3.0.1?
>
> 1. Work was being done on it up to the last minute where our
> release was delayed a day because of it.
> 2. There are no docs written about the feature and thus, the work
> is NOT complete (docs are the other 1/2 of the solution).
> 3. The rush to get the feature in caused sloppy hacks --
> ComputerVerificationStrategy exception addition, configuration keys that
> don't conform to standard practices, ??.
> 4. It required the time of other committers to focus on this as
> opposed to doing their work thus, effecting their attention to other
> details of the release.
> 5. Stephen and I are now having to spend time figuring out how to
> do the 3.0.1 release --- time and focus wasted on pointless inanities.
>
> If you are not going to do things right, then please save your work for
> another release when you have the time to think, document, and test things
> thoroughly. In particular to BLVP, there is no reason to slip this feature
> in to 3.0.1. Why not save it for 3.1.0?
>
> In short, please don't procrastinate (though I think BLVP was more of a
> rush issue) and don't make hasty decisions to "just get things working."
>
> Give a hoot, don't pollute.
>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>
>
Re: Contributing to TinkerPop -- Please do not rush your work.
Posted by Matt Frantz <ma...@gmail.com>.
Process improvement suggestion: How about a "hack freeze" period before a
release, so that all changes must go through PR and code review by a peer?
On Wed, Sep 2, 2015 at 6:27 AM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hello,
>
> If you are going to commit work to a branch that is about to be released,
> either do it right or save it for another release. We can not have last
> minute features causing problems for our committers and our users.
>
> In particular, as an example, I'm calling out BulkLoaderVertexProgram. Why
> was including this feature bad for 3.0.1?
>
> 1. Work was being done on it up to the last minute where our
> release was delayed a day because of it.
> 2. There are no docs written about the feature and thus, the work
> is NOT complete (docs are the other 1/2 of the solution).
> 3. The rush to get the feature in caused sloppy hacks --
> ComputerVerificationStrategy exception addition, configuration keys that
> don't conform to standard practices, ??.
> 4. It required the time of other committers to focus on this as
> opposed to doing their work thus, effecting their attention to other
> details of the release.
> 5. Stephen and I are now having to spend time figuring out how to
> do the 3.0.1 release --- time and focus wasted on pointless inanities.
>
> If you are not going to do things right, then please save your work for
> another release when you have the time to think, document, and test things
> thoroughly. In particular to BLVP, there is no reason to slip this feature
> in to 3.0.1. Why not save it for 3.1.0?
>
> In short, please don't procrastinate (though I think BLVP was more of a
> rush issue) and don't make hasty decisions to "just get things working."
>
> Give a hoot, don't pollute.
>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>
>