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 14:41:58 GMT
Fluo can be deployed without any of these tools.

All of them are optional/supplemental.

On Fri, Aug 5, 2016, 10:35 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 :)
>
> 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