Sounds great Darin.
On Fri, Sep 23, 2016 at 9:16 PM, Darin Johnson
wrote:
> Reposting the Google doc to this thread for cohesion.
> https://docs.google.com/document/d/1K8E0TridC1hBfqDwWCqdZ8Dj_5_
> mMrRQyynQ-Q6MFbI/edit?usp=sharing
>
> If there's no issues I'd like to start this, since it involv
Reposting the Google doc to this thread for cohesion.
https://docs.google.com/document/d/1K8E0TridC1hBfqDwWCqdZ8Dj_5_mMrRQyynQ-Q6MFbI/edit?usp=sharing
If there's no issues I'd like to start this, since it involves a lot of
file moves (which are a pain to revise) my plan is to break it into a few
m
Great
Will have pirk-63 sometime this weekend, which will help. Then go ahead
with these suggestions as a base, I may come back with some thoughts about
the cli. I'd like for new responders not to modify pirk-core. There's a
few ways I've done this before, but need to decide which will be least
On Thu, Sep 15, 2016 at 9:25 AM, Tim Ellison wrote:
> On 15/09/16 09:21, Darin Johnson wrote:
> > So my goal for the submodule refactor is pretty straight forward, I
> > basically want to separate the project into: pirk-core, pirk-hadoop,
> > pirk-spark, and pirk-storm. I think separating pirk-c
On 15/09/16 09:21, Darin Johnson wrote:
> So my goal for the submodule refactor is pretty straight forward, I
> basically want to separate the project into: pirk-core, pirk-hadoop,
> pirk-spark, and pirk-storm. I think separating pirk-core and pirk-hadoop
> is very ambitious at this point as there
So my goal for the submodule refactor is pretty straight forward, I
basically want to separate the project into: pirk-core, pirk-hadoop,
pirk-spark, and pirk-storm. I think separating pirk-core and pirk-hadoop
is very ambitious at this point as there's a lot of dependencies we'd need
to resolve.
+1 to start a sub-thread. I would suggest to start a shared Google Doc for
dumping ideas and evolving a structure.
On Wed, Sep 14, 2016 at 2:48 PM, Ellison Anne Williams <
eawilli...@apache.org> wrote:
> Starting a new thread to discuss the Pirk submodule refactor (so that we
> don't get too mixe
