If we (taking off Fluo PPMC hat) do consider donating them to Apache, and we (putting Fluo PPMC hat back on) consider accepting them into the Fluo project, I think it'd be best to hold off until Fluo is an established TLP. Right now, I think the PPMC needs to focus on Fluo itself, to get it established, before it spreads out and takes on additional responsibility for related-software. Just my personal opinion.
On Fri, Aug 5, 2016 at 2:33 PM Mike Walch <[email protected]> wrote: > Just to clarify things.. > > If you want to run Fluo, you need set up dependencies (Hadoop, Accumulo, > Zookeeper) and deploy/start a Fluo application on top of them. The > upcoming Apache Fluo release gives you everything you need to deploy/start > Fluo. It allows you to start Fluo as local processes or as application in > YARN. In the future, I would like to support more ways to start/deploy > Fluo (like to Mesos/Marathon, Kubernetes, etc) and have all of this code be > part of Apache Fluo (but maybe as separate repos). > > Uno & Muchos handle setting up dependencies and not deployment. After you > run 'uno setup' or 'muchos setup', you will have Accumulo, Hadoop, and > Zookeeper running but you still need to use the 'fluo' command (which is > distributed with Apache Fluo) to deploy your Fluo application to YARN. > > While I think we should hold off on moving Uno & Muchos to Apache Fluo, I > am open to moving them to Apache in the future if it make senses. > > On Fri, Aug 5, 2016 at 11:17 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 :) > > > > Sorry for the spam everyone. I just keep thinking of nuances. These > > tools are also extremely useful for testing and experimenting with > > just Accumulo. I use Muchos all of the time to test Accumulo RCs on > > EC2 (and do nothing with 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. > > >>>>>>>> > > >> > > > > > >
