fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Trademark discussions and plan
Date Fri, 05 Aug 2016 18:51:32 GMT
If we (taking off Fluo PPMC hat) do consider donating them to Apache, and
we (putting Fluo PPMC hat back on) consider accepting them into the Fluo
project, I think it'd be best to hold off until Fluo is an established TLP.
Right now, I think the PPMC needs to focus on Fluo itself, to get it
established, before it spreads out and takes on additional responsibility
for related-software. Just my personal opinion.

On Fri, Aug 5, 2016 at 2:33 PM Mike Walch <mwalch@gmail.com> wrote:

> 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