incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Date Mon, 01 Aug 2016 22:00:41 GMT
On Mon, Aug 1, 2016 at 5:23 PM John D. Ament <> wrote:

> On Mon, Aug 1, 2016 at 4:21 PM Christopher <> wrote:
> > On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <>
> > wrote:
> >
> > > On Mon, Aug 1, 2016 at 10:29 AM Keith Turner <> wrote:
> > >
> > > > On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament <
> >
> > > > 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 "" first, and is in the process of being granted to
> > the ASF during its incubation, while "" 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, but not sites like or which are
related to the ASF project, but clearly not owned or controlled by ASF? Or
even The last one has a disclaimer about who owns
the "Maven" trademark. Would it still be a problem for "" if
it also had a similar disclaimer?

> And just to be clear, 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,
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?

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

This will be fixed. The * site is the canonical location for
Fluo. It may link to related projects at, and other external sites,
for convenience, but Fluo itself will be documented at the *
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
> (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.

> - becomes the canonical source for release announcements, user
> guides, etc.

That will not be the case. is in a transition period. It currently
redirects to, 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 with Apache Fluo and 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 for Fluo documentation, and it will contain a footer
indicating that Fluo is a trademark of the Apache Software Foundation.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message