On Mon, Aug 1, 2016 at 5:23 PM John D. Ament <johndam...@apache.org> wrote:
> On Mon, Aug 1, 2016 at 4:21 PM Christopher <ctubb...@apache.org> wrote: > > > On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <johndam...@apache.org> > > wrote: > > > > > On Mon, Aug 1, 2016 at 10:29 AM Keith Turner <ke...@deenlo.com> wrote: > > > > > > > On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament <johndam...@apache.org > > > > > > wrote: > > > > > I'm -1 until the website issues are resolved. > > > > > > > > > > - Make sure its clear that any existing releases are not apache > > > endorsed. > > > > > - Make sure the website points to resources contained within the > ASF, > > > > e.g. > > > > > fluo-dev is a bit of an oddity same for zetten. > > > > > > > > Is there a policy on what ASF websites can link to? > > > > > > > > > > Yes. You have a branding issue. Fluo is a name owned by the ASF at > this > > > point. > > > > > > I'm not sure that's been determined yet. Fluo has not yet completed the > > podling name search, and the name "Fluo" did not originate at Apache. It > > was in use at "fluo.io" first, and is in the process of being granted to > > the ASF during its incubation, while "fluo.io" transitions to what is > > essentially a "Fluo fan site" which provides third-party Fluo-related > > projects, which the Fluo community may find useful. > > > > This is problematic. I'm OK with splitting the discussions out into a > separate thread between IPMC and Fluo's PPMC. But just so you're clear, > this doesn't sit well with me in its current form. > > Why would this be a concern for http://fluo.io, but not sites like http://www.stratahadoopworld.com/ or http://accumulosummit.com/ which are related to the ASF project, but clearly not owned or controlled by ASF? Or even http://search.maven.org/? The last one has a disclaimer about who owns the "Maven" trademark. Would it still be a problem for "http://fluo.io"; if it also had a similar disclaimer? > And just to be clear, fluo.io redirects to fluo.a.o. My qualm within this > thread has been against: > > - The use of a tool "fluo-dev" being required to run fluo, but not > developed within the ASF and sharing the name assigned to the podling. > The tool "fluo-dev" is *NOT* required to run Fluo. It is an independent tool which helps create a standalone deployment of Fluo, Accumulo, Hadoop, and ZooKeeper, for local development and testing of that stack. It's not part of Fluo and is not required for Fluo development. Fluo depend on it in any way. It's documented on the website for convenience, in case developers choose to make use of it. If that's not clear, we can make sure that it is. > - The usage of dependencies within the release being against older > coordinates with what I can tell have no plans to move over to the ASF > naming structure. > > It's not an "older" coordinates... it's a separate artifact, independent of any project which moved to ASF. It is the current release of the "resources" artifact from the "io.fluo" group. It'd be just as if the project had a dependency on any other artifact in Maven Central to provide formatter/checkstyle rules.... say, for instance, de.greenrobot:checkstyle-rules:jar:2.0.0, which is released by the "de.greenrobot" group instead of "io.fluo" group. > > > > > I'd expect these branding issues to block graduation, but I wouldn't > > normally expect these sorts of issues to prevent incubating releases. > > There's got to be some precedent in Incubator for projects which have > been > > transitioned like this? > > > > The most recent I can think of is TinkerPop/Gremlin. Which had most things > squared away until some weird stuff happened right at the end of their > incubation process. You have no affiliation with DataStax do you? > > No. > > > > > > > > Is there a reason why these resources (fluo dev and zetten) aren't > > > hosted within ASF managed git repos? > > > > > > > > Yes. They are not being granted to the ASF for various reasons. First, > > fluo-dev and zetten don't have "releases" in any ASF sense, and Zetten > has > > dependencies whose licenses are not suitable for an ASF project by > policy. > > > > The plan was that the originating community for Fluo would continue to > > operate Fluo.io as a third-party Fluo-related website hosting > Fluo-related > > community projects in the same way that many other Apache projects have > > communities larger than what fits inside ASF. > > > > This is where things get a little shaky for me. If its truly powered by a > community, and not a commercial entity, it should be fine. Some of the > signs that can pop up: > > - All of the documentation on how to use the software links from fluo.a.o > into fluo.io. > This will be fixed. The *.apache.org site is the canonical location for Fluo. It may link to related projects at fluo.io, and other external sites, for convenience, but Fluo itself will be documented at the *.apache.org site. Keep in mind, that much of this hasn't been updated yet, because we haven't actually been able to get as far as producing a Fluo 1.0.0-incubating release, which would drive meaningful updates to the site from the legacy content. We haven't been able to get that far, because we're currently blocked on releasing our parent POM. > - The only way you can use fluo is by using some magic provided by fluo.io > (which is where I have a concern over fluo-dev with how its described) > As stated above, this is not true. It is a misconception. Fluo-dev is not required for Fluo in any way. It's an independent effort to make launching the full Fluo stack on a single machine easier, for development/testing. > - fluo.io becomes the canonical source for release announcements, user > guides, etc. > That will not be the case. Fluo.io is in a transition period. It currently redirects to fluo.apache.org, because we wanted Fluo users to be aware of Fluo's transition to the ASF, through the incubator. However, we realize now that redirection was a mistake, because it confuses things and conflates the scope of fluo.io with Apache Fluo and fluo.apache.org. We will fix this, so that it will no longer redirect, and its contents will be scoped to the independent tools it provides. It will defer to Apache Fluo's home at apache.org for Fluo documentation, and it will contain a footer indicating that Fluo is a trademark of the Apache Software Foundation.
