fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Walch <mwa...@gmail.com>
Subject Re: [DISCUSS] Trademark discussions and plan
Date Fri, 05 Aug 2016 18:32:44 GMT
Just to clarify things..

If you want to run Fluo, you need set up dependencies (Hadoop, Accumulo,
Zookeeper) and deploy/start a Fluo application on top of them.  The
upcoming Apache Fluo release gives you everything you need to deploy/start
Fluo.  It allows you to start Fluo as local processes or as application in
YARN.  In the future, I would like to support more ways to start/deploy
Fluo (like to Mesos/Marathon, Kubernetes, etc) and have all of this code be
part of Apache Fluo (but maybe as separate repos).

Uno & Muchos handle setting up dependencies and not deployment.  After you
run 'uno setup' or 'muchos setup', you will have Accumulo, Hadoop, and
Zookeeper running but you still need to use the 'fluo' command (which is
distributed with Apache Fluo) to deploy your Fluo application to YARN.

While I think we should hold off on moving Uno & Muchos to Apache Fluo, I
am open to moving them to Apache in the future if it make senses.

On Fri, Aug 5, 2016 at 11:17 AM Keith Turner <keith@deenlo.com> wrote:

> On Fri, Aug 5, 2016 at 10:34 AM, Josh Elser <josh.elser@gmail.com> wrote:
> > While this does fall into ASF guidelines, I do not agree that relying on
> > external projects (or vendors as is often the case elsewhere) for
> deploying
> > your software is a good idea.
> >
> > I'm of the opinion that you should at least have one way in Apache Fluo
> that
> > people can use to deploy Apache Fluo. That's just my opinion on the
> matter
> > though :)
>
> Sorry for the spam everyone.  I just keep thinking of nuances.  These
> tools are also extremely useful for testing and experimenting with
> just Accumulo.  I use Muchos all of the time to test Accumulo RCs on
> EC2 (and do nothing with Fluo).
>
>
> >
> >
> > Christopher wrote:
> >>
> >> Good points, Mike. I agree with that position. I agree with
> >> linking/supporting/making room for independent innovation in the area of
> >> cluster management and integration, rather than incorporating them into
> >> the
> >> Apache Fluo PPMC responsibilities.
> >>
> >> On Wed, Aug 3, 2016 at 3:32 PM Mike Walch<mwalch@apache.org>  wrote:
> >>
> >>> My view is that Apache Fluo should only contain code the used to run
> >>> Fluo.
> >>> We should avoid bringing in any projects that run the entire stack (i.e
> >>> Hadoop, Accumulo, Zookeeper, etc) like fluo-dev and zetten (now called
> >>> Uno
> >>> and Muchos).  While some users may find Uno/Muchos useful, others might
> >>> prefer to integrate Fluo in their own development stack or cluster
> >>> management tool.
> >>>
> >>> If we move Uno/Muchos into Apache Fluo, then we should be willing to
> >>> accept
> >>> similar contributions (like a development tool that starts the Fluo
> stack
> >>> in docker or vagrant or a Chef script that launches Fluo and it
> >>> dependences
> >>> on cluster).  If we accept every project like this, we create a heavy
> >>> maintenance burden for Apache Fluo.  If we only move Uno/Muchos and not
> >>> others, then it will look we are endorsing them over of other tools.
> >>>
> >>> I would rather link to these tools from the Apache Fluo website and
> give
> >>> users as many options as possible on how they want to run Fluo. There
> is
> >>> so
> >>> much innovation going on in cluster management.  I would rather make
> room
> >>> for a several external projects compete and innovate rather than
> endorse
> >>> a
> >>> certain tool (even if its the ones that I helped create).
> >>>
> >>> On Wed, Aug 3, 2016 at 1:37 PM Keith Turner<keith@deenlo.com>  wrote:
> >>>
> >>>> On Wed, Aug 3, 2016 at 12:37 PM, Josh Elser<josh.elser@gmail.com>
> >>>
> >>> wrote:
> >>>>>
> >>>>>
> >>>>> Christopher wrote:
> >>>>>>
> >>>>>> On Tue, Aug 2, 2016 at 3:37 PM Josh Elser<josh.elser@gmail.com>
> >>>
> >>> wrote:
> >>>>>>>
> >>>>>>> Christopher wrote:
> >>>>>>>>
> >>>>>>>> Okay, so we've been having a long discussion regarding
trademarks
> as
> >>>>
> >>>> the
> >>>>>>>>
> >>>>>>>> project transitions from fluo.io to fluo.apache.org
on the
> >>>
> >>> incubator
> >>>>>>>
> >>>>>>> list (
> >>>>>>>
> >>>>>>>
> >>>
> >>>
> https://lists.apache.org/thread.html/69a0c4befd56240ac642c4912e7497ea53720920a459e923f5cf7e91@%3Cgeneral.incubator.apache.org%3E
> >>>>>>>
> >>>>>>> ).
> >>>>>>>>
> >>>>>>>> Several issues arose, and Keith, Mike and I have been
discussing
> >>>
> >>> what
> >>>>
> >>>> we
> >>>>>>>>
> >>>>>>>> think is the best plan forward.
> >>>>>>>>
> >>>>>>>> What we think is best:
> >>>>>>>>
> >>>>>>>> 1. Create a branch in the incubator-fluo repo for the
resources,
> and
> >>>>
> >>>> do
> >>>>>>>
> >>>>>>> an
> >>>>>>>>
> >>>>>>>> Apache release of the checkstyle/formatter rules in
that resources
> >>>>
> >>>> jar.
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>>> 2. Update the parent POM to use that resources jar instead
of the
> >>>>>>>> previously released io.fluo one.
> >>>>>>>
> >>>>>>> Is there are reason these resource jars were not included
with the
> >>>>>>> parent pom release?
> >>>>>>>
> >>>>>>>
> >>>>>> Not a very good reason. The main reason is that the released
> artifact
> >>>>>> already existed and was suitable. There's also a chicken-egg
issue
> >>>
> >>> that
> >>>>>>
> >>>>>> makes things a bit annoying doing new releases of the resources
> >>>>
> >>>> object...
> >>>>>>
> >>>>>> because it can't depend on the parent POM. It's also versioned
> >>>>
> >>>> separately.
> >>>>>>
> >>>>>> But mostly, there was no immediate need for a new one any time
soon
> >>>
> >>> when
> >>>>>>
> >>>>>> the current one works fine.
> >>>>>>
> >>>>> So would you think a new repo is appropriate for this? Would you
want
> >>>
> >>> to
> >>>>>
> >>>>> just use the same Git repo that the parent pom exists in (put two
> >>>>
> >>>> separate
> >>>>>
> >>>>> maven projects inside)?
> >>>>>
> >>>>> As far as tech goes, I don't think this is super critical, but the
> >>>>
> >>>> feelings
> >>>>>
> >>>>> aspect of it might require more immediate action.
> >>>>>
> >>>>>>>> 5. Open a discussion on trademarks@apache.org to determine
> whether
> >>>>
> >>>> the
> >>>>>>>>
> >>>>>>>> GitHub organization "fluo-io" should be renamed, and
what would be
> >>>
> >>> an
> >>>>>>>>
> >>>>>>>> acceptable name for a GitHub organization containing
fluo-related
> >>>
> >>> 3rd
> >>>>>>>
> >>>>>>> party
> >>>>>>>>
> >>>>>>>> projects. Also determine whether it is acceptable to
use the
> >>>
> >>> trademark
> >>>>>>>
> >>>>>>> for
> >>>>>>>>
> >>>>>>>> fluo-related extensions repository names (eg. "fluo-stress"
and
> >>>>>>>> "fluo-quickstart").
> >>>>>>>
> >>>>>>> My feeling is that with proper distinction that "fluo-io"
is not
> >>>>>>> affiliated with "Apache Fluo (incubating)" and the ASF but
are
> >>>
> >>> related
> >>>>>>>
> >>>>>>> software projects would be fine. Admittedly, I'm not sure
the
> >>>
> >>> reasoning
> >>>>>>>
> >>>>>>> behind wanting to keep them separate (was there a reason
these were
> >>>
> >>> not
> >>>>>>>
> >>>>>>> included in the original donation?) and bringing them under
the ASF
> >>>>>>> umbrella would make sense to me.
> >>>>>>>
> >>>>>>>
> >>>>>> As discussed on the thread, some of the projects are not appropriate
> >>>
> >>> for
> >>>>>>
> >>>>>> ASF, and were not part of the original donation. I agree with
your
> >>>>>> assessment (and I also made the argument) that "fluo-io" can
be
> >>>
> >>> properly
> >>>>>>
> >>>>>> distinguished from "Apache Fluo" and the ASF, with some effort.
That
> >>>>
> >>>> would
> >>>>>>
> >>>>>> be the position we'd bring to trademarks@. But also, if we give
up
> >>>
> >>> the
> >>>>>>
> >>>>>> domain "fluo.io", either by donation to ASF or by letting it
lapse,
> >>>
> >>> it
> >>>>>>
> >>>>>> will
> >>>>>> not longer make sense for the GitHub org to be called "fluo-io",
and
> >>>
> >>> it
> >>>>>>
> >>>>>> might make more sense to rename it to something like "fluo-tools".
> >>>>>> Regardless, if it has "fluo" in the name, we'll want to get
it
> cleared
> >>>>
> >>>> as
> >>>>>>
> >>>>>> an approved use of the trademark.
> >>>>>
> >>>>>
> >>>>> Yeah, I'm not sure what to recommend for maintaining such an org.
> Let's
> >>>>
> >>>> make
> >>>>>
> >>>>> sure to tread very carefully. Because the maintainers/creators of
> these
> >>>>> tools that were not brought to Apache are the PPMC now, this has
the
> >>>>> potential to be misconstrued.
> >>>>>
> >>>>> Would it be out of line for me to suggest that for the projects
> >>>>
> >>>> currently at
> >>>>>
> >>>>> github.com/fluo-io:
> >>>>>
> >>>>> * Specifically decree those with no interest to maintain as such
> >>>>> * Make a plan to bring others into the Apache umbrella
> >>>>>
> >>>>> I know this is a bit totalitarian, but I'm not sure how to avoid
> >>>
> >>> further
> >>>>>
> >>>>> drama over an organization of fluo-related software projects,
> >>>
> >>> maintained
> >>>>
> >>>> by
> >>>>>
> >>>>> a subset of the PPMC.
> >>>>
> >>>> This seems unnecessary to me for the following reasons :
> >>>>
> >>>>   * Not all software built on top of an Apache project needs to reside
> >>>> at
> >>>> Apache
> >>>>   * Its ok for people on the PPMC of a project work on whatever they
> >>>> want outside of Apache.
> >>>>   * The precedents set by what we do with these projects need to scale
> >>>> to any user of Fluo.  I would like to avoid setting the precedent of
> >>>> accepting drive by contributions of projects that build on Fluo and
> >>>> are not maintained by anyone.
> >>>>
> >>>> I think its fine for these projects to exists outside of Apache for
> >>>> now and possibly move to Apache in the future if we become more
> >>>> certain about their direction.  I don' think we should do anything
> >>>> hasty w/o a good plan.
> >>>>
> >>>> I think the main thing we need to do in the short term is clean up
> >>>> using the Fluo name in these external projects, like rename fluo-dev
> >>>> to something else. Also need to rename the fluo-io github org to
> >>>> something else.  Zetten already has a good name.   We also need to
> >>>> clean up the links to the projects on the website to add proper
> >>>> context (that these projects are optional and may be helpful) and
> >>>> disclaimers.
> >>>>
> >>>> We may want to move some of them, not sure yet (but again I don't
> >>>> think we should hurry and set bad precedents).   Also it m be best to
> >>>> discuss plans for each external project individually (or in groups).
> >>>> For example the need for fluo-quickstart may completely go away.  I
am
> >>>> working on new Fluo Tour for the website and it needs a small
> >>>> associated git repo (with pom and basic java code) to help people get
> >>>> started quickly.  I was thinking of re-purposing fluo-quickstart for
> >>>> this.  However, Christopher suggested that since this  bit of code
> >>>> will be so closely associated with web site that we could put in a
> >>>> branch on the existing fluo-website repo.  I really like this
> >>>> solution, but Christopher pointed out that it does not make sense for
> >>>> fluo-stress, phrasecount,  and webindex.  I agree that it does not
> >>>> make sense for these.
> >>>>
> >>>>
> >>>>>>> Regardless, VP of trademarks has a much heavier weight of
opinion
> >>>
> >>> than
> >>>>
> >>>> I
> >>>>>>>
> >>>>>>> do. A healthy discussion sounds great.
> >>>>>>>
> >>>>>>>> 6. Complete the PODLINGNAMESEARCH, so all this effort
to protect
> the
> >>>>>>>
> >>>>>>> "Fluo"
> >>>>>>>>
> >>>>>>>> trademark isn't done in vain.
> >>>>>>>
> >>>>>>> +1 this isn't that hard to do either. Feel free to ask for
> >>>>
> >>>> help/guidance.
> >>>>>>>
> >>>>>>>
> >>>>>> Please help. :)
> >>>>>> But seriously, we did create the JIRA issue, but have not yet
> >>>>
> >>>> contributed
> >>>>>>
> >>>>>> to documenting the fact-finding there yet.
> >>>>>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-109
> >>>>>
> >>>>>
> >>>>> :) ok. Let's break this one out. I think we should get the other
> items
> >>>>
> >>>> here
> >>>>>
> >>>>> done and then we can come back to the namesearch after (it's good
to
> >>>
> >>> get
> >>>>
> >>>> it
> >>>>>
> >>>>> done early, but not as important as the other branding concerns).
> >>>>>
> >>>>>
> >>>>>>>> I'll go ahead and get started on item 1, because I think
that
> should
> >>>>
> >>>> be
> >>>>>>>>
> >>>>>>>> relatively easy to do.
> >>>>>>>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message