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 Wed, 03 Aug 2016 19:38:46 GMT
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