fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Trademark discussions and plan
Date Fri, 05 Aug 2016 15:08:07 GMT
On Fri, Aug 5, 2016 at 10:55 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 :)
>
> There may be a misunderstanding about what these tools do.  If you
> have an existing cluster with YARN, Zookeeper, and Accumulo already
> running then out of the box the Fluo tarball can run there (w/o the
> need for these external tools).
>
> These external tools are to help developers quickly create an
> environment with Hadoop, ZK and Accumulo running.   These tools are
> targeted for users trying out Fluo and testing Fluo only and not
> recommended for production use.  For production use I would personally
> recommend a user look into using one of the Hadoop vendors.

A clarification on this.  I would personally recommend hadoop vendors
for YARN,ZK, and Accumulo if a user asked about running Fluo in
production.  The Fluo community can not provide support for the entire
stack Fluo depends on.  We can only provide bug fixes for 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
View raw message