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:04:45 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.
>
> 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 :)

Oh one more important point.  These tools are not required for a user
to start playing with Fluo either.   With MiniAccumulo+MiniFluo all a
user need to start playing with Fluo is maven+java.  The Fluo tour
that I am working on for the website will only rely on MiniFluo.


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