Fluo can be deployed without any of these tools. All of them are optional/supplemental.
On Fri, Aug 5, 2016, 10:35 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 :) > > 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. > >>>>>>> > > >
