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 :)
Oh one more important point. These tools are not required for a user to start playing with Fluo either. With MiniAccumulo+MiniFluo all a user need to start playing with Fluo is maven+java. The Fluo tour that I am working on for the website will only rely on MiniFluo. > > > 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. >>>>>>>> >> >
