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 14:57:22 GMT
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.


These tools are somewhat similar to the many ways people have created
to run the full Accumulo stack over the years (ie vagrant, chef,
docker, etc) because setting up the Accumulo and its dependencies from
scratch is a lot of work.

>
> 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 :)
>
>
> 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