On Fri, Aug 5, 2016 at 10:55 AM, Keith Turner <[email protected]> wrote: > On Fri, Aug 5, 2016 at 10:34 AM, Josh Elser <[email protected]> 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 :) > > There may be a misunderstanding about what these tools do. If you > have an existing cluster with YARN, Zookeeper, and Accumulo already > running then out of the box the Fluo tarball can run there (w/o the > need for these external tools). > > These external tools are to help developers quickly create an > environment with Hadoop, ZK and Accumulo running. These tools are > targeted for users trying out Fluo and testing Fluo only and not > recommended for production use. For production use I would personally > recommend a user look into using one of the Hadoop vendors.
A clarification on this. I would personally recommend hadoop vendors for YARN,ZK, and Accumulo if a user asked about running Fluo in production. The Fluo community can not provide support for the entire stack Fluo depends on. We can only provide bug fixes for 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<[email protected]> 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<[email protected]> wrote: >>>> >>>>> On Wed, Aug 3, 2016 at 12:37 PM, Josh Elser<[email protected]> >>>> >>>> wrote: >>>>>> >>>>>> >>>>>> Christopher wrote: >>>>>>> >>>>>>> On Tue, Aug 2, 2016 at 3:37 PM Josh Elser<[email protected]> >>>> >>>> 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 [email protected] 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. >>>>>>>>> >>> >>
