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. > > >>>> > > >> > > > > > >
