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. 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 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. > > 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 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. - 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) - fluo.io becomes the canonical source for release announcements, user guides, etc.
