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 19:00:03 GMT
On Fri, Aug 5, 2016 at 2:48 PM, Josh Elser <josh.elser@gmail.com> wrote:
> Thanks for all the points, Keith and Mike. This was very helpful to me. I
> assumed formerly-known-as-Zetten was more about deploying Fluo itself, but
> it seems it is more about the prerequisites for Fluo. I was just assuming a
> bit too much it seems :)
>
> While it might be a little premature before there is an official release, I
> think instructions on the website for how a user installs/configures Fluo
> would be great and help attract new users.

This will happen.  Mike has been taking markdown instructions in Fluo
itself and posting those on the website in the past.   This includes
install instructions.   I just put up a PR to remove the links to
fluo-dev (now called Uno) and zetten (now called Muchos) from those
install instructions.  I think this is a nice improvement.   The
install instructions should not have been pointing to those w/o the
caveat about not using them for production.  But I think its better
just not pointing to them at all.

https://github.com/apache/incubator-fluo/pull/754

>
> Mike Walch 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
View raw message