You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Christopher <ct...@apache.org> on 2016/07/30 18:14:15 UTC
[VOTE] Fluo Parent POM 1-incubating (rc2)
In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
first separately releasing a parent POM. This release passed a PPMC vote on
the Fluo dev@ list here:
https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
Please consider the following candidate for Fluo Parent POM 1-incubating.
Git Commit:
(https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
e9ed4334dd4cc5df27def417f26d6d7362470cb8
Branch:
fluo-parent-1-rc2
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
Staging repo:
https://repository.apache.org/content/repositories/orgapachefluo-1003
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
(Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
given artifact.)
Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
Please vote one of:
[ ] +1 - I have verified and accept...
[ ] +0 - I have reservations, but not strong enough to vote against...
[ ] -1 - Because..., I do not accept...
... these artifacts as the 1-incubating release of Apache Fluo Parent POM.
This vote will end on Tue Aug 02 18:30:00 UTC 2016
(Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
Thanks!
P.S. Hint: download the whole staging repo with
wget -erobots=off -r -l inf -np -nH \
https://repository.apache.org/content/repositories/orgapachefluo-1003/
# note the trailing slash is needed
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Sat, Jul 30, 2016 at 10:07 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Also you seem to non approved releases [1] on your Apache website [2]
> please remove these or make it clear that these are not Apache releases
> (which I assume is the case).
>
>
Good catch. Thanks. Those releases were non-Apache releases prior to
joining incubation. We'll fix that.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Also you seem to non approved releases [1] on your Apache website [2] please remove these or make it clear that these are not Apache releases (which I assume is the case).
Thanks,
Justin
1. http://www.apache.org/dev/release.html#what
2. https://fluo.apache.org/docs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Sat, Jul 30, 2016 at 11:14 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> No it doesn’t put the files in the mirrors. [6] The dev area is not
> mirrored. You can release them with a simple svn move command.
>
Since the policy allows for the use of the staging repositories at
repository.apache.org for voting, and because that is already automated by
Maven and the configuration in the ASF-wide Parent POM, I think it's easier
to stick with that for now.
However, because also staging it in SVN would make it easier to do a
release with "svn mv", I'll investigate automating uploads to the SVN
/dist/dev area during the "mvn release:perform" executing when the upload
to the Nexus staging repository also occurs.
> > Regarding "apache-" as a filename prefix
>
> It’s a good idea as it may give you some extra legal protection and make
> it clear from a branding point of view that it’s an Apache project. Is it
> required by policy? Not that I’m aware but most projects I’ve been involved
> in do have apache in the release name.
>
>
I think I understand some reasons for not doing this for Maven projects
(excessive redundancy in the Maven GAV coordinates, and because it would
make it harder for forks/vendor distributions to build variants without
renaming all the artifacts to avoid trademark violations), I wonder what
some of the reasons non-Maven projects at ASF, like httpd, don't do this in
their release artifacts?
> Thanks,
> Justin
>
> 1. https://dist.apache.org/repos/dist/dev/incubator/
> 2. http://www.apache.org/dev/release-distribution#maven
> 3. http://www.apache.org/dev/release.html#where-do-releases-go
> 4. http://www.apache.org/dev/release-distribution#channels
> 5. http://www.apache.org/dev/release-distribution#public-distribution
> 6. http://www.apache.org/dev/release.html#stage
>
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I know you voted +1, so I think you're okay with it as-is this time around. Is this correct?
Yep, it only a minor thing.
> I'm still a little confused about the location to place the files
> pre-release for voting. Should I understand that there is an "official"
> staging area to use for voting?
Yes and it’s [1], the apache nexus is a secondary area.[2] See also [3][4][5]. Note the MAY in [2] but the MUST in [5].
> it's my understanding that people used to upload
> artifacts to people.apache.org/~user/ prior to that
That changed about 5 years ago ;-)
> We can additionally put the same artifacts in /dev/dist (what is the full
> location?). Does that put the files in the mirrors?
No it doesn’t put the files in the mirrors. [6] The dev area is not mirrored. You can release them with a simple svn move command.
> Regarding "apache-" as a filename prefix
It’s a good idea as it may give you some extra legal protection and make it clear from a branding point of view that it’s an Apache project. Is it required by policy? Not that I’m aware but most projects I’ve been involved in do have apache in the release name.
Thanks,
Justin
1. https://dist.apache.org/repos/dist/dev/incubator/
2. http://www.apache.org/dev/release-distribution#maven
3. http://www.apache.org/dev/release.html#where-do-releases-go
4. http://www.apache.org/dev/release-distribution#channels
5. http://www.apache.org/dev/release-distribution#public-distribution
6. http://www.apache.org/dev/release.html#stage
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
Thanks Justin. I have a few questions still.
On Sat, Jul 30, 2016 at 10:26 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> +1 binding
>
> I checked:
> - release name includes incubating
> - signature and hashes correct
> - DISCLAIMER exits
> - LICENSE and NOTICE correct. Although you might want to add
> “(incubating)” after the project name in NOTICE.
>
In order for us to add "(incubating)" with a reproducible build, we'd have
to re-do this release. Is it alright if that happened on the next version,
or should we re-do this one? I know you voted +1, so I think you're okay
with it as-is this time around. Is this correct?
> - No source files to check for Apache headers
>
I think the pom.xml file is technically a source file, and does have the
Apache header, but it also has the <license /> section, so it might be
redundant. The apache-rat-plugin does check that one or the other exists.
We kept both in to be sure.
> - No binary files in release
> - Can “compile” without any issues
>
> The release needs be placed in the /dev/dist incubator area. It's also a
> good idea to include the word “apache” in the release file name.
>
>
I'm still a little confused about the location to place the files
pre-release for voting. Should I understand that there is an "official"
staging area to use for voting? We followed the streamlined process done in
the Accumulo project, by using the Apache Nexus staging area at
repository.apache.org (it's my understanding that people used to upload
artifacts to people.apache.org/~user/ prior to that), relying on the fact
that once the staging repository is closed, it can't be modified and has a
unique identifier.
We can additionally put the same artifacts in /dev/dist (what is the full
location?). Does that put the files in the mirrors? If so, I'd think we'd
want to avoid that until after the vote.
Regarding "apache-" as a filename prefix:
In order for the filename to have "apache-" in it, we'd have to add that to
the Maven artifactId, which would make things pretty redundant for its
maven coordinates. Either that, or we'd just rename the file after being
created from the rules set forth in the ASF-wide parent POM's execution of
the maven-assembly-plugin in its apache-release profile. I don't really see
too many other projects doing this... to include httpd, accumulo, hadoop,
thrift, and lots of others. (some do, though, like Kudu and Tomcat).
We'd like to keep the build and release process as simplified and automatic
as possible, taking advantage of the standards set forth in the ASF-wide
Parent POM and good Maven-coordinates naming conventions. Is this "apache-"
naming prefix that important? Because it would be a bit of hoop jumping to
make this reproducible and automated with Maven.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
+1 binding
I checked:
- release name includes incubating
- signature and hashes correct
- DISCLAIMER exits
- LICENSE and NOTICE correct. Although you might want to add “(incubating)” after the project name in NOTICE.
- No source files to check for Apache headers
- No binary files in release
- Can “compile” without any issues
The release needs be placed in the /dev/dist incubator area. It's also a good idea to include the word “apache” in the release file name.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Aug 2, 2016 at 11:18 AM, Keith Turner <ke...@deenlo.com> wrote:
> On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament <jo...@apache.org> wrote:
>> I'm -1 until the website issues are resolved.
>>
>> - Make sure its clear that any existing releases are not apache endorsed.
>
> One interesting thing this discussion has highlighted that we didn't
> realize was the following :
>
> 1. Releases of Fluo before moving to apache were made available via
> the fluo-io/fluo repo on GH
> 2. The GitHub projects fluo and fluo-recipes were transferred to the
> apache org on GH from the fluo-io repo on GH. The downloads came
> along for the ride when the transfer happened.
> 3. Now the downloads[1] look like ASF artifacts (because they under
> the apache GH org) to someone not familiar with this history and ASF
> release practices.
>
> What should we do about this? Personally I would like to delete the
> old artifacts[1] from GH after we have a 1.0.0-incubating release of
> Fluo. Is it ok to leave them there for now and is it ok for
> fluo.apache.org to link to them with a disclaimer?
We just updated the website, you may need to force refresh to see
updates. It no longer[1] has links to the pre-Apache releases (they
still exist on Github). Still need guidance on adding links w/
disclaimers to the pre-Apache releases.
We still have the documentation for the pre-Apache releases on the
website, but have added very prominent disclaimers (see [2][3][4] for
examples).
[1]: http://fluo.apache.org/download/
[2]: http://fluo.apache.org/docs/
[3]: http://fluo.apache.org/docs/pre-asf/
[4]: http://fluo.apache.org/docs/fluo/1.0.0-beta-2/prod-fluo-setup/
>
> This will be something to look out for in the future when projects
> transfer GH repos to Apache.
>
> [1]: https://github.com/apache/incubator-fluo/releases
>
>> - Make sure the website points to resources contained within the ASF, e.g.
>> fluo-dev is a bit of an oddity same for zetten.
>> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
>> within your pom files. Its still not clear to me why your parent declares
>> dependencies on previously released artifacts and why those can't be
>> bundled within the release.
>>
>> John
>>
>> On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
>>
>>> io.fluo was the groupId for Fluo before it transitioned to incubation. This
>>> parent POM references a previously released (prior to acceptance into
>>> incubation) resources artifact under that identity, which contains
>>> checkstyle and Eclipse code formatter rules which this project still uses
>>> to apply consistent formatting and style checks to maven projects using
>>> this parent POM.
>>>
>>> On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
>>> wrote:
>>>
>>> > What is io.fluo and why does this depend on it? Sounds like a branding
>>> > issue.
>>> >
>>> > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
>>> >
>>> > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
>>> > > first separately releasing a parent POM. This release passed a PPMC
>>> vote
>>> > on
>>> > > the Fluo dev@ list here:
>>> > >
>>> > >
>>> >
>>> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
>>> > >
>>> > > Please consider the following candidate for Fluo Parent POM
>>> 1-incubating.
>>> > >
>>> > > Git Commit:
>>> > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
>>> > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
>>> > > Branch:
>>> > > fluo-parent-1-rc2
>>> > >
>>> > > If this vote passes, a gpg-signed tag will be created using:
>>> > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
>>> > > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
>>> > >
>>> > > Staging repo:
>>> > > https://repository.apache.org/content/repositories/orgapachefluo-1003
>>> > > Source (official release artifact):
>>> > >
>>> > >
>>> >
>>> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
>>> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
>>> > > given artifact.)
>>> > >
>>> > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>>> > >
>>> > > Please vote one of:
>>> > > [ ] +1 - I have verified and accept...
>>> > > [ ] +0 - I have reservations, but not strong enough to vote against...
>>> > > [ ] -1 - Because..., I do not accept...
>>> > > ... these artifacts as the 1-incubating release of Apache Fluo Parent
>>> > POM.
>>> > >
>>> > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
>>> > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
>>> > >
>>> > > Thanks!
>>> > >
>>> > > P.S. Hint: download the whole staging repo with
>>> > > wget -erobots=off -r -l inf -np -nH \
>>> > >
>>> > https://repository.apache.org/content/repositories/orgapachefluo-1003/
>>> > > # note the trailing slash is needed
>>> > >
>>> >
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament <jo...@apache.org> wrote:
> I'm -1 until the website issues are resolved.
>
> - Make sure its clear that any existing releases are not apache endorsed.
One interesting thing this discussion has highlighted that we didn't
realize was the following :
1. Releases of Fluo before moving to apache were made available via
the fluo-io/fluo repo on GH
2. The GitHub projects fluo and fluo-recipes were transferred to the
apache org on GH from the fluo-io repo on GH. The downloads came
along for the ride when the transfer happened.
3. Now the downloads[1] look like ASF artifacts (because they under
the apache GH org) to someone not familiar with this history and ASF
release practices.
What should we do about this? Personally I would like to delete the
old artifacts[1] from GH after we have a 1.0.0-incubating release of
Fluo. Is it ok to leave them there for now and is it ok for
fluo.apache.org to link to them with a disclaimer?
This will be something to look out for in the future when projects
transfer GH repos to Apache.
[1]: https://github.com/apache/incubator-fluo/releases
> - Make sure the website points to resources contained within the ASF, e.g.
> fluo-dev is a bit of an oddity same for zetten.
> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
> within your pom files. Its still not clear to me why your parent declares
> dependencies on previously released artifacts and why those can't be
> bundled within the release.
>
> John
>
> On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
>
>> io.fluo was the groupId for Fluo before it transitioned to incubation. This
>> parent POM references a previously released (prior to acceptance into
>> incubation) resources artifact under that identity, which contains
>> checkstyle and Eclipse code formatter rules which this project still uses
>> to apply consistent formatting and style checks to maven projects using
>> this parent POM.
>>
>> On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
>> wrote:
>>
>> > What is io.fluo and why does this depend on it? Sounds like a branding
>> > issue.
>> >
>> > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
>> >
>> > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
>> > > first separately releasing a parent POM. This release passed a PPMC
>> vote
>> > on
>> > > the Fluo dev@ list here:
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
>> > >
>> > > Please consider the following candidate for Fluo Parent POM
>> 1-incubating.
>> > >
>> > > Git Commit:
>> > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
>> > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
>> > > Branch:
>> > > fluo-parent-1-rc2
>> > >
>> > > If this vote passes, a gpg-signed tag will be created using:
>> > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
>> > > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
>> > >
>> > > Staging repo:
>> > > https://repository.apache.org/content/repositories/orgapachefluo-1003
>> > > Source (official release artifact):
>> > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
>> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
>> > > given artifact.)
>> > >
>> > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>> > >
>> > > Please vote one of:
>> > > [ ] +1 - I have verified and accept...
>> > > [ ] +0 - I have reservations, but not strong enough to vote against...
>> > > [ ] -1 - Because..., I do not accept...
>> > > ... these artifacts as the 1-incubating release of Apache Fluo Parent
>> > POM.
>> > >
>> > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
>> > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
>> > >
>> > > Thanks!
>> > >
>> > > P.S. Hint: download the whole staging repo with
>> > > wget -erobots=off -r -l inf -np -nH \
>> > >
>> > https://repository.apache.org/content/repositories/orgapachefluo-1003/
>> > > # note the trailing slash is needed
>> > >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Craig Russell <cr...@oracle.com>.
> On Aug 3, 2016, at 12:25 PM, Christopher <ct...@apache.org> wrote:
>
> On Wed, Aug 3, 2016 at 9:14 AM Vice President, Brand Management <
> vp-brand@apache.org> wrote:
>
>>
>> In particular, using another third party's potential branding mis-use to
>> justify your desired uses of an Apache brand is a danger sign, and one
>> that likely will draw more scrutiny to your question.
>>
> Understood. But, as I previously explained, that wasn't my reasons for
> using those examples. I was highlighting what I believed to be acceptable
> use, and trying to find a path of acceptability for our situation, similar
> to those. I certainly was not trying to highlight mis-use to justify
> further mis-use.
Thanks for clarifying. I believe that you were and are acting in good faith.
>
>> Your community needs to decide what you're doing with the "fluo" name -
>> either keep it for yourself, and choose a new name for the podling, or
>> grant it to the ASF (during the Incubation process), and choose a new,
>> unrelated name for your outside projects.
>>
> We've followed the second route... renaming the fluo-io organization on
> GitHub to astralway, and are in the process of removing use of the Fluo
> name everywhere except when referencing Apache Fluo explicitly.
Excellent choice. It looks like there are no conflicts with “astralway” so you should be fine there.
>
> I actually had expected to be asking explicit questions on trademarks@
> soon, but given the route we've taken, I actually don't think we have any
> outstanding trademark questions/requests to follow up with. Our next RC
> brought to the IPMC shouldn't have any remaining trademark concerns.
Good luck and it’s been a pleasure working with you on this issue.
Regards,
Craig
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Wed, Aug 3, 2016 at 9:14 AM Vice President, Brand Management <
vp-brand@apache.org> wrote:
>
> In particular, using another third party's potential branding mis-use to
> justify your desired uses of an Apache brand is a danger sign, and one
> that likely will draw more scrutiny to your question.
>
>
Understood. But, as I previously explained, that wasn't my reasons for
using those examples. I was highlighting what I believed to be acceptable
use, and trying to find a path of acceptability for our situation, similar
to those. I certainly was not trying to highlight mis-use to justify
further mis-use.
> Your community needs to decide what you're doing with the "fluo" name -
>
either keep it for yourself, and choose a new name for the podling, or
> grant it to the ASF (during the Incubation process), and choose a new,
> unrelated name for your outside projects.
>
>
We've followed the second route... renaming the fluo-io organization on
GitHub to astralway, and are in the process of removing use of the Fluo
name everywhere except when referencing Apache Fluo explicitly.
I actually had expected to be asking explicit questions on trademarks@
soon, but given the route we've taken, I actually don't think we have any
outstanding trademark questions/requests to follow up with. Our next RC
brought to the IPMC shouldn't have any remaining trademark concerns.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "Vice President, Brand Management" <vp...@apache.org>.
(Please note the From: address)
Christopher wrote on 8/1/16 6:36 PM:
> On Mon, Aug 1, 2016 at 6:22 PM Craig Russell <cr...@oracle.com>
> wrote:
>
>> Hi Christopher,
>>
>>> On Aug 1, 2016, at 3:00 PM, Christopher <ct...@apache.org> wrote:
>>>
>>> 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?
Ever project's branding questions are distinct and independent from any
other project's branding questions. While I'm happy to have people ask
- in separate threads - "Is Foo project OK with blah?", that in no way
means that those examples are good ones to follow.
In particular, using another third party's potential branding mis-use to
justify your desired uses of an Apache brand is a danger sign, and one
that likely will draw more scrutiny to your question.
>>>
>>
>> The reason I\u2019m pushing back on fluo being in compliance with Apache
>> trademark policy is that we currently have a mess with several other
>> projects. PMCs are having a difficult time defending Apache\u2019s brands.
>>
>>
> We don't want to add to that list. We want to find some way to be compliant
> without hurting the project or its community which extends outside of the
> ASF. We previously had a single entity (fluo.io), and we're trying to split
> into two distinct entities (an ASF PMC at fluo.apache.org, and an
> independent community of related tools at fluo.io) with non-overlapping,
> but clearly complimentary, scopes.
That will cause your project to fail to graduate.
The trademark for the project can only be used by one organization -
either the ASF, or by someone else. Not both.
Your community needs to decide what you're doing with the "fluo" name -
either keep it for yourself, and choose a new name for the podling, or
grant it to the ASF (during the Incubation process), and choose a new,
unrelated name for your outside projects.
I do appreciate the questions, and understand the points about other
semi-related software bits or different licenses. But Apache projects
must be branded as Apache projects, and not share the actual name or
governance - or perception of governance - with outside groups.
>
>
>> \u201cThe other guys are not in compliance so we don\u2019t have to be\u201d is not a
>> good response. We are trying to straighten out other misuses of Apache
>> trademarks and don\u2019t want any more issues while we figure out how to fix
>> the others.
>>
>>
> That wasn't what I was trying to say. I was trying to say that it seems
> like there are circumstances similar to what we are trying to achieve which
> are, in fact, acceptable uses of trademark. I wasn't pointing out that
> these other sites aren't compliant. I was pointing out that we'd like to
> move towards whatever it takes to fall within these acceptable
> circumstances which apply to these others.
Reading the event branding policy would be helpful to explain some of
the other branding uses. Events are a different trademark category than
software products, and we have an explicit approval process for event
related brands.
http://www.apache.org/foundation/marks/events
>
> So, my goal here is to find what is reasonable and acceptable for our
> situation.
>
--
- Shane Curcuru
Vice President, Brand Management
The Apache Software Foundation
http://www.apache.org/foundation/marks
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 6:22 PM Craig Russell <cr...@oracle.com>
wrote:
> Hi Christopher,
>
> > On Aug 1, 2016, at 3:00 PM, Christopher <ct...@apache.org> wrote:
> >
> > 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?
> >
>
> The reason I’m pushing back on fluo being in compliance with Apache
> trademark policy is that we currently have a mess with several other
> projects. PMCs are having a difficult time defending Apache’s brands.
>
>
We don't want to add to that list. We want to find some way to be compliant
without hurting the project or its community which extends outside of the
ASF. We previously had a single entity (fluo.io), and we're trying to split
into two distinct entities (an ASF PMC at fluo.apache.org, and an
independent community of related tools at fluo.io) with non-overlapping,
but clearly complimentary, scopes.
> “The other guys are not in compliance so we don’t have to be” is not a
> good response. We are trying to straighten out other misuses of Apache
> trademarks and don’t want any more issues while we figure out how to fix
> the others.
>
>
That wasn't what I was trying to say. I was trying to say that it seems
like there are circumstances similar to what we are trying to achieve which
are, in fact, acceptable uses of trademark. I wasn't pointing out that
these other sites aren't compliant. I was pointing out that we'd like to
move towards whatever it takes to fall within these acceptable
circumstances which apply to these others.
So, my goal here is to find what is reasonable and acceptable for our
situation.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Craig Russell <cr...@oracle.com>.
Hi Christopher,
> On Aug 1, 2016, at 3:00 PM, Christopher <ct...@apache.org> wrote:
>
> 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?
>
The reason I’m pushing back on fluo being in compliance with Apache trademark policy is that we currently have a mess with several other projects. PMCs are having a difficult time defending Apache’s brands.
“The other guys are not in compliance so we don’t have to be” is not a good response. We are trying to straighten out other misuses of Apache trademarks and don’t want any more issues while we figure out how to fix the others.
Craig
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 5:23 PM John D. Ament <jo...@apache.org> wrote:
> On Mon, Aug 1, 2016 at 4:21 PM Christopher <ct...@apache.org> wrote:
>
> > On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <jo...@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 <johndament@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.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 5:32 PM Craig Russell <cr...@oracle.com>
wrote:
>
> Apache will not allow an independent organization to use an Apache brand
> name outside the brand guidelines.
>
>
I think the relevant portion is in
http://www.apache.org/foundation/marks/#domains:
"You may not use ASF trademarks such as "Apache" or "ApacheFoo" or "Foo" in
your own domain names if that use would be likely to confuse a relevant
consumer about the source of software or services provided through your
website..."
The policy doesn't completely prevent the use of "Foo" in the domain name,
but only if it "...would be likely to confuse...". I would think that could
be addressed by clearly documenting on fluo.io that "Fluo.io" is not
affiliated with "Apache Fluo", and that Fluo is a trademark of the Apache
Software Foundation, while "Fluo.io" is a website which provides
Fluo-related community tools not officially endorsed by the ASF.
We have considered the possibility of donating fluo.io to the ASF... but
because the site is also linked to non-ASF projects on GitHub, some of
which do not meet ASF policies (zetten depends on Ansible, which is GPLv3),
and we do not wish to abandon those projects, or relocate them, because
they have already been established at their current location.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Craig Russell <cr...@oracle.com>.
> On Aug 1, 2016, at 2:22 PM, John D. Ament <jo...@apache.org> wrote:
>
> On Mon, Aug 1, 2016 at 4:21 PM Christopher <ct...@apache.org> wrote:
>
>> On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <jo...@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 <jo...@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’ll chime in here as well. I won’t comment on the VOTE issue but will note that fluo will not graduate unless Apache has trademark rights to the name. And if Apache owns the fluo name, this would necessitate fluo.io changing their name or being under control of Apache.
Apache will not allow an independent organization to use an Apache brand name outside the brand guidelines.
Craig
>
>>
>> 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.
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Aug 1, 2016 at 4:21 PM Christopher <ct...@apache.org> wrote:
> On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <jo...@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 <jo...@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.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 3:50 PM John D. Ament <jo...@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 <jo...@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.
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?
> 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.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@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. Is there a reason why these resources (fluo dev and zetten) aren't
hosted within ASF managed git repos?
>
> > - Make sure that io.fluo is either replaced, or has a ticket to be
> replaced
> > within your pom files. Its still not clear to me why your parent
> declares
> > dependencies on previously released artifacts and why those can't be
> > bundled within the release.
> >
> > John
> >
> > On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
> >
> >> io.fluo was the groupId for Fluo before it transitioned to incubation.
> This
> >> parent POM references a previously released (prior to acceptance into
> >> incubation) resources artifact under that identity, which contains
> >> checkstyle and Eclipse code formatter rules which this project still
> uses
> >> to apply consistent formatting and style checks to maven projects using
> >> this parent POM.
> >>
> >> On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
> >> wrote:
> >>
> >> > What is io.fluo and why does this depend on it? Sounds like a
> branding
> >> > issue.
> >> >
> >> > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
> >> >
> >> > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo
> team is
> >> > > first separately releasing a parent POM. This release passed a PPMC
> >> vote
> >> > on
> >> > > the Fluo dev@ list here:
> >> > >
> >> > >
> >> >
> >>
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
> >> > >
> >> > > Please consider the following candidate for Fluo Parent POM
> >> 1-incubating.
> >> > >
> >> > > Git Commit:
> >> > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> >> > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> >> > > Branch:
> >> > > fluo-parent-1-rc2
> >> > >
> >> > > If this vote passes, a gpg-signed tag will be created using:
> >> > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> >> > > rel/fluo-parent-1-incubating
> e9ed4334dd4cc5df27def417f26d6d7362470cb8
> >> > >
> >> > > Staging repo:
> >> > >
> https://repository.apache.org/content/repositories/orgapachefluo-1003
> >> > > Source (official release artifact):
> >> > >
> >> > >
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> >> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash
> for a
> >> > > given artifact.)
> >> > >
> >> > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> >> > >
> >> > > Please vote one of:
> >> > > [ ] +1 - I have verified and accept...
> >> > > [ ] +0 - I have reservations, but not strong enough to vote
> against...
> >> > > [ ] -1 - Because..., I do not accept...
> >> > > ... these artifacts as the 1-incubating release of Apache Fluo
> Parent
> >> > POM.
> >> > >
> >> > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
> >> > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
> >> > >
> >> > > Thanks!
> >> > >
> >> > > P.S. Hint: download the whole staging repo with
> >> > > wget -erobots=off -r -l inf -np -nH \
> >> > >
> >> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/
> >> > > # note the trailing slash is needed
> >> > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament <jo...@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?
> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
> within your pom files. Its still not clear to me why your parent declares
> dependencies on previously released artifacts and why those can't be
> bundled within the release.
>
> John
>
> On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
>
>> io.fluo was the groupId for Fluo before it transitioned to incubation. This
>> parent POM references a previously released (prior to acceptance into
>> incubation) resources artifact under that identity, which contains
>> checkstyle and Eclipse code formatter rules which this project still uses
>> to apply consistent formatting and style checks to maven projects using
>> this parent POM.
>>
>> On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
>> wrote:
>>
>> > What is io.fluo and why does this depend on it? Sounds like a branding
>> > issue.
>> >
>> > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
>> >
>> > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
>> > > first separately releasing a parent POM. This release passed a PPMC
>> vote
>> > on
>> > > the Fluo dev@ list here:
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
>> > >
>> > > Please consider the following candidate for Fluo Parent POM
>> 1-incubating.
>> > >
>> > > Git Commit:
>> > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
>> > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
>> > > Branch:
>> > > fluo-parent-1-rc2
>> > >
>> > > If this vote passes, a gpg-signed tag will be created using:
>> > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
>> > > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
>> > >
>> > > Staging repo:
>> > > https://repository.apache.org/content/repositories/orgapachefluo-1003
>> > > Source (official release artifact):
>> > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
>> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
>> > > given artifact.)
>> > >
>> > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>> > >
>> > > Please vote one of:
>> > > [ ] +1 - I have verified and accept...
>> > > [ ] +0 - I have reservations, but not strong enough to vote against...
>> > > [ ] -1 - Because..., I do not accept...
>> > > ... these artifacts as the 1-incubating release of Apache Fluo Parent
>> > POM.
>> > >
>> > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
>> > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
>> > >
>> > > Thanks!
>> > >
>> > > P.S. Hint: download the whole staging repo with
>> > > wget -erobots=off -r -l inf -np -nH \
>> > >
>> > https://repository.apache.org/content/repositories/orgapachefluo-1003/
>> > > # note the trailing slash is needed
>> > >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Henry Saputra <he...@gmail.com>.
I recommend the Fluo PPMCs to go back and work it out with trademarks and
the Mentors of the podling.
Even some of top level projects have problems regarding their trademarks,
and the incubator should be the place to learn what is needed to learn how
to protect the project trademarks.
Good luck guys!
- Henry
On Mon, Aug 1, 2016 at 6:52 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Aug 1, 2016 at 8:09 PM John D. Ament <jo...@apache.org>
> wrote:
>
> > Ok, now I'm a bit confused. I'll try my best to state my points of
> > clarification in line.
> >
> > On Mon, Aug 1, 2016 at 7:37 PM Christopher <ct...@apache.org> wrote:
> >
> > > I also wish to point out that the FluoProposal (
> > > http://wiki.apache.org/incubator/FluoProposal) explicitly included an
> > > intent/wish/request to continue using the Fluo logo (which includes the
> > > name) on Fluo's historical sites. That proposal was accepted by the
> IPMC
> > >
> >
> > I'm confused what this has to do with a logo. I see now in your proposal
> > that there's an explicit call out for the logo. I'm not sure why. Its a
> > nice logo. Assuming it was donated as a part of the overall donation,
> then
> > there's no issue reusing it on other sites.
> >
> >
> It was donated along with the rest of the code from the Fluo repository and
> the Fluo I only offer this, to point out that it was identified up front
> that the name (which is contained in the logo) was identified as something
> which we'd like to continue to use at the original site, at least in a
> limited sense.
>
>
> >
> > > (albeit without an explicit judgment on that issue). While the proposal
> > did
> > > not explicitly mention the domain name concerns, it did mention the
> > > continued existence of "historical sites" after acceptance, sites whose
> > > names could reasonably be expected to contain the Fluo name. I think
> this
> > > is important in determining to what extent it should be considered fair
> > and
> > > reasonable to use the word "Fluo" on "fluo.io".
> > >
> >
> > The term "historical" is used in the proposal. My interpretation of its
> > use is that some sites may exist for historical purposes. It seems that
> > the intention however is to keep them going. The list of sites are not
> > mentioned, other than a GitHub site, which I'm not sure if that means
> > fluo.github.io, github.com/fluo-io, or something else. Its not obvious
> to
> > me that this is fluo.io which may be hosted as a github pages website.
> >
> >
> The specific list of sites are not mentioned (outside of GitHub), but the
> intention was to get blanket approval for all such historical sites. We
> specifically called out the logo, because we anticipated trademark
> considerations for that. We never anticipated that there'd be a trademark
> concern over the name Fluo, because we didn't really think that alone would
> be an issue, especially when separated from the word "Apache" (a mistake on
> our part for not anticipating that). One of the reasons we didn't
> anticipate that is because "Fluo" was incorporated as part of the overall
> organization on GitHub and the corresponding website, as "fluo-io", and "
> fluo.io" respectively. It was mentioned that only some of the Fluo code
> would be transferred. Specifically, the repositories "fluo" and
> "fluo-recipes", as indicated in the "Git repository" section with requested
> ASF repos of "incubator-fluo.git" and "incubator-fluo-recipes.git".
>
> So, it was always indicated that not all of the repositories at fluo.io
> (GitHub org fluo-io) were being granted. We did not expect that it would be
> necessary to relocate these to another site/organization name to deconflict
> the branding concerns.
>
>
> >
> > >
> > > At no point in the proposal or vote discussions for Fluo was it
> mentioned
> > > that we'd have to remove or transfer control of the fluo.io domain, in
> > > order to be compliant with ASF trademark policies upon acceptance into
> > > Incubator, even though it was clear at the time that 1) the domain
> > existed
> > > and 2) hosted projects which would transfer to the ASF and projects
> which
> > > would not.
> > >
> >
> > The proposal is a bit missing in this area. I see a documentation
> section,
> > which mentions the website fluo.io. Ignoring this discussion, my
> > interpretation of this section is that it was being donated. Yes,
> > transference of domain names is expected. Many projects coming in have
> > done this (groovy-lang.org, freemarker.org are some examples). If it
> was
> > not intended to be transferred, its not clear to me why its mentioned in
> > the proposal.
> >
>
> Agreed that the proposal was missing some info, in hindsight. The docs (at
> least, the relevant ones) were expected to be transferred along with the
> code. It was shortsighted on our part for not considering the what would
> happen with the whole domain and the other repos/docs.
>
> I believe our understanding of the Documentation section, according to
> http://incubator.apache.org/guides/proposal.html#template-documentation
> was
> the description "References to further reading material.", which seemed to
> indicate that the section was for informational purposes, and not related
> to what would be transferred.
>
>
> >
> > >
> > > Taking this into account, and in conjunction with our intent to fix
> both
> > > websites to reduce confusion, I hope that we can find a resolution
> which
> > > does not require a name change, but can leave both fluo.apache.org and
> > > fluo.io coexisting.
> > >
> > >
> > The co-existing part is where you need to talk more to TM and get their
> buy
> > in. Right now we have a highly inconsistent model at the ASF.
> >
>
> Okay, so it sounds like we need to open a thread on the TM mailing list to
> resolve, before bringing the discussion back to the incubator list. I think
> we'll still want to try to follow at least some of the below path also, to
> help get approval on the TM list.
>
>
> >
> >
> > I think our immediate, actionable plan should be to:
> > >
> > > 1. Remove redirect from fluo.io to fluo.apache.org
> >
> >
> > I'm not sure if you're doing this out of anger or what. The current
> setup
> > of redirect is fine.
> >
> >
> Certainly not out of anger. The redirect simply shouldn't be there, since
> that site served as documentation for Fluo, as well as the other projects
> in the fluo-io GitHub organization, which are not part of Fluo itself, and
> not part of ASF. I believe the redirect was performed in error to begin
> with. Removing the redirect would be a correction, and would help
> distinguish between what is Apache, and what is unaffiliated with Apache.
>
>
> >
> > >
> > > 2. Place content on fluo.io which:
> > > 2.a) links to Apache Fluo
> > > 2.b) states that Fluo is a trademark of Apache
> > > 2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
> > > 2.d) is primarily focused on the community tools it hosts, and not
> > Apache
> > > Fluo
> >
> > 3. Ensure content on fluo.apache.org is updated to:
> > > 3.a) remove pre-apache release or clearly document them.
> > > 3.b) remove any implication that Fluo depends on any software at
> > fluo.io
> > > 3.c) ensure no dependency on external documentation at fluo.io
> >
> >
> > All of the items under 3 are great graduation goals, and are not needed
> in
> > the short term.
> >
> >
> There was a -1 in this thread pending at least some of the website issues,
> so I think we'll probably want them in the short-term as well. It would
> also help with the pending TM list discussion we'll want to have.
>
>
> >
> > >
> > > 4. Standardize on a different publicly available checkstyle and
> formatter
> > > ruleset than the io.fluo:resources ones (maybe?)
> > >
> >
> > Just to be clear. my concern here is shared with the domain name. If
> the
> > domain name is cleared to be used, I don't have a strong concern on this.
> >
> >
> Gotcha. We'll revisit that after the TM discussion about the fluo.io
> domain
> name, then, if necessary.
>
>
> >
> > >
> > > If we're going to expend this effort, it would be nice to get some
> > > assurances that this will be sufficient to resolve branding concerns,
> or
> > if
> > > there are additional steps short of changing the domain names, which we
> > can
> > > take to resolve these issues.
> > >
> >
> >
> > My recommendation is that fluo.io be donated to the ASF and a new domain
> > name chosen for the non-ASF community backed site.
> >
>
> We'll need to discuss this further, but I think our preferred option is
> going to be (in order of preference):
>
> 1. Get approval from TM about continued use of the fluo.io domain as an
> unaffiliated community site.
> 2. Choose a new name for the podling project.
> 3. Your recommendation above.
>
> Thanks for the good discussion. This has helped raise a lot of issues we
> hadn't previously considered, and helped clarify what we need to do next.
> I'm optimistic that the end result will be a clear path forward which
> serves the community well.
>
> Should I CC this list for the trademarks@ list discussion? Or just provide
> a lists.apache.org link?
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Tue, Aug 2, 2016 at 1:02 AM Alex Harui <ah...@adobe.com> wrote:
>
>
> On 8/1/16, 6:52 PM, "Christopher" <ct...@apache.org> wrote:
>
> >> My recommendation is that fluo.io be donated to the ASF and a new
> domain
> >> name chosen for the non-ASF community backed site.
> >>
> >
> >We'll need to discuss this further, but I think our preferred option is
> >going to be (in order of preference):
> >
> >1. Get approval from TM about continued use of the fluo.io domain as an
> >unaffiliated community site.
> >2. Choose a new name for the podling project.
> >3. Your recommendation above.
>
> From the peanut gallery:
>
> My understanding is that there are "strong" marks and "weak(er)" marks,
> that, AIUI, is related to how much usage of the TM is already out there,
> how many were actually approved, and to what degree un-approved mark usage
> was pursued by the mark holder.
>
> Flex, for example, is a "weaker" mark. When Adobe donated the Flex TM to
> Apache, there were dozens of domains with 'flex' in it both related to
> Adobe Flex and other things like cars, delivery services, even other
> software like lexers. I'm pretty sure neither Apache nor Adobe went
> around to all of the flex domains related to Apache Flex and made them get
> permission to continue using their domain name, but Adobe did redirect
> flex.org to Apache (although I just noticed it isn't responding). AIUI,
> if we find out that someone is using flex.biz, flex.us, or any other
> flex.* domain, even if they are helping to promote Apache Flex, we are
> supposed to ask them to use something else. But I believe there is more
> flexibility around using flex as part of the domain name.
>
> So, IMO, I will be surprised if fluo.io gets approved for non-ASF usage.
> I think, though, that fluo.io could redirect to a page on the podling site
> that explains that why fluo.io doesn't do what it used to do, and even
> have a link to what was at fluo.io but with a new domain name, maybe
> fluo-tools or tools-for-fluo.io. AIUI, you can link to web sites that
> aren't under ASF-friendly licensing as long as there are disclaimers on
> your page.
>
> HTH (but of course, I could be wrong),
> -Alex
>
>
The nuance with fluo.io is that it never represented itself as, say, "Fluo
in the .io top-level domain", for example. Rather, it has always been "
fluo.io" or "fluo-io". Just "fluo" has always been a subset of what is in
the "fluo.io" domain. So, it's somewhat like how "bit.ly" represents the
"bitly" entity. If "bitly" developed a product called "bit", and donated it
to Apache as "Apache Bit", nobody would suggest "bit.ly" is now infringing.
Granted, this case wouldn't be as clear as that, because "bitly" is a
well-established corporate entity, but "fluo.io" is just a small organized
group of projects/tools related to Fluo. But, it's how I see it: "fluo.io"
is not the same as "the domain for fluo". Changing to something like
"fluo-tools.whatever" might be suitable as an alternative, but from my
perspective, that's what "fluo.io" already is. We'll see what TM has to say.
Note: if all of the projects under fluo.io were suitable for a home in ASF,
we'd have been more than happy moving them all over and donating the
domain. The fact that some of its projects are inherently unsuitable (GPL
dependencies, repos with no intention to ever release, etc.) motivate me to
want to keep them separate.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Alex Harui <ah...@adobe.com>.
On 8/1/16, 6:52 PM, "Christopher" <ct...@apache.org> wrote:
>> My recommendation is that fluo.io be donated to the ASF and a new domain
>> name chosen for the non-ASF community backed site.
>>
>
>We'll need to discuss this further, but I think our preferred option is
>going to be (in order of preference):
>
>1. Get approval from TM about continued use of the fluo.io domain as an
>unaffiliated community site.
>2. Choose a new name for the podling project.
>3. Your recommendation above.
From the peanut gallery:
My understanding is that there are "strong" marks and "weak(er)" marks,
that, AIUI, is related to how much usage of the TM is already out there,
how many were actually approved, and to what degree un-approved mark usage
was pursued by the mark holder.
Flex, for example, is a "weaker" mark. When Adobe donated the Flex TM to
Apache, there were dozens of domains with 'flex' in it both related to
Adobe Flex and other things like cars, delivery services, even other
software like lexers. I'm pretty sure neither Apache nor Adobe went
around to all of the flex domains related to Apache Flex and made them get
permission to continue using their domain name, but Adobe did redirect
flex.org to Apache (although I just noticed it isn't responding). AIUI,
if we find out that someone is using flex.biz, flex.us, or any other
flex.* domain, even if they are helping to promote Apache Flex, we are
supposed to ask them to use something else. But I believe there is more
flexibility around using flex as part of the domain name.
So, IMO, I will be surprised if fluo.io gets approved for non-ASF usage.
I think, though, that fluo.io could redirect to a page on the podling site
that explains that why fluo.io doesn't do what it used to do, and even
have a link to what was at fluo.io but with a new domain name, maybe
fluo-tools or tools-for-fluo.io. AIUI, you can link to web sites that
aren't under ASF-friendly licensing as long as there are disclaimers on
your page.
HTH (but of course, I could be wrong),
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 8:09 PM John D. Ament <jo...@apache.org> wrote:
> Ok, now I'm a bit confused. I'll try my best to state my points of
> clarification in line.
>
> On Mon, Aug 1, 2016 at 7:37 PM Christopher <ct...@apache.org> wrote:
>
> > I also wish to point out that the FluoProposal (
> > http://wiki.apache.org/incubator/FluoProposal) explicitly included an
> > intent/wish/request to continue using the Fluo logo (which includes the
> > name) on Fluo's historical sites. That proposal was accepted by the IPMC
> >
>
> I'm confused what this has to do with a logo. I see now in your proposal
> that there's an explicit call out for the logo. I'm not sure why. Its a
> nice logo. Assuming it was donated as a part of the overall donation, then
> there's no issue reusing it on other sites.
>
>
It was donated along with the rest of the code from the Fluo repository and
the Fluo I only offer this, to point out that it was identified up front
that the name (which is contained in the logo) was identified as something
which we'd like to continue to use at the original site, at least in a
limited sense.
>
> > (albeit without an explicit judgment on that issue). While the proposal
> did
> > not explicitly mention the domain name concerns, it did mention the
> > continued existence of "historical sites" after acceptance, sites whose
> > names could reasonably be expected to contain the Fluo name. I think this
> > is important in determining to what extent it should be considered fair
> and
> > reasonable to use the word "Fluo" on "fluo.io".
> >
>
> The term "historical" is used in the proposal. My interpretation of its
> use is that some sites may exist for historical purposes. It seems that
> the intention however is to keep them going. The list of sites are not
> mentioned, other than a GitHub site, which I'm not sure if that means
> fluo.github.io, github.com/fluo-io, or something else. Its not obvious to
> me that this is fluo.io which may be hosted as a github pages website.
>
>
The specific list of sites are not mentioned (outside of GitHub), but the
intention was to get blanket approval for all such historical sites. We
specifically called out the logo, because we anticipated trademark
considerations for that. We never anticipated that there'd be a trademark
concern over the name Fluo, because we didn't really think that alone would
be an issue, especially when separated from the word "Apache" (a mistake on
our part for not anticipating that). One of the reasons we didn't
anticipate that is because "Fluo" was incorporated as part of the overall
organization on GitHub and the corresponding website, as "fluo-io", and "
fluo.io" respectively. It was mentioned that only some of the Fluo code
would be transferred. Specifically, the repositories "fluo" and
"fluo-recipes", as indicated in the "Git repository" section with requested
ASF repos of "incubator-fluo.git" and "incubator-fluo-recipes.git".
So, it was always indicated that not all of the repositories at fluo.io
(GitHub org fluo-io) were being granted. We did not expect that it would be
necessary to relocate these to another site/organization name to deconflict
the branding concerns.
>
> >
> > At no point in the proposal or vote discussions for Fluo was it mentioned
> > that we'd have to remove or transfer control of the fluo.io domain, in
> > order to be compliant with ASF trademark policies upon acceptance into
> > Incubator, even though it was clear at the time that 1) the domain
> existed
> > and 2) hosted projects which would transfer to the ASF and projects which
> > would not.
> >
>
> The proposal is a bit missing in this area. I see a documentation section,
> which mentions the website fluo.io. Ignoring this discussion, my
> interpretation of this section is that it was being donated. Yes,
> transference of domain names is expected. Many projects coming in have
> done this (groovy-lang.org, freemarker.org are some examples). If it was
> not intended to be transferred, its not clear to me why its mentioned in
> the proposal.
>
Agreed that the proposal was missing some info, in hindsight. The docs (at
least, the relevant ones) were expected to be transferred along with the
code. It was shortsighted on our part for not considering the what would
happen with the whole domain and the other repos/docs.
I believe our understanding of the Documentation section, according to
http://incubator.apache.org/guides/proposal.html#template-documentation was
the description "References to further reading material.", which seemed to
indicate that the section was for informational purposes, and not related
to what would be transferred.
>
> >
> > Taking this into account, and in conjunction with our intent to fix both
> > websites to reduce confusion, I hope that we can find a resolution which
> > does not require a name change, but can leave both fluo.apache.org and
> > fluo.io coexisting.
> >
> >
> The co-existing part is where you need to talk more to TM and get their buy
> in. Right now we have a highly inconsistent model at the ASF.
>
Okay, so it sounds like we need to open a thread on the TM mailing list to
resolve, before bringing the discussion back to the incubator list. I think
we'll still want to try to follow at least some of the below path also, to
help get approval on the TM list.
>
>
> I think our immediate, actionable plan should be to:
> >
> > 1. Remove redirect from fluo.io to fluo.apache.org
>
>
> I'm not sure if you're doing this out of anger or what. The current setup
> of redirect is fine.
>
>
Certainly not out of anger. The redirect simply shouldn't be there, since
that site served as documentation for Fluo, as well as the other projects
in the fluo-io GitHub organization, which are not part of Fluo itself, and
not part of ASF. I believe the redirect was performed in error to begin
with. Removing the redirect would be a correction, and would help
distinguish between what is Apache, and what is unaffiliated with Apache.
>
> >
> > 2. Place content on fluo.io which:
> > 2.a) links to Apache Fluo
> > 2.b) states that Fluo is a trademark of Apache
> > 2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
> > 2.d) is primarily focused on the community tools it hosts, and not
> Apache
> > Fluo
>
> 3. Ensure content on fluo.apache.org is updated to:
> > 3.a) remove pre-apache release or clearly document them.
> > 3.b) remove any implication that Fluo depends on any software at
> fluo.io
> > 3.c) ensure no dependency on external documentation at fluo.io
>
>
> All of the items under 3 are great graduation goals, and are not needed in
> the short term.
>
>
There was a -1 in this thread pending at least some of the website issues,
so I think we'll probably want them in the short-term as well. It would
also help with the pending TM list discussion we'll want to have.
>
> >
> > 4. Standardize on a different publicly available checkstyle and formatter
> > ruleset than the io.fluo:resources ones (maybe?)
> >
>
> Just to be clear. my concern here is shared with the domain name. If the
> domain name is cleared to be used, I don't have a strong concern on this.
>
>
Gotcha. We'll revisit that after the TM discussion about the fluo.io domain
name, then, if necessary.
>
> >
> > If we're going to expend this effort, it would be nice to get some
> > assurances that this will be sufficient to resolve branding concerns, or
> if
> > there are additional steps short of changing the domain names, which we
> can
> > take to resolve these issues.
> >
>
>
> My recommendation is that fluo.io be donated to the ASF and a new domain
> name chosen for the non-ASF community backed site.
>
We'll need to discuss this further, but I think our preferred option is
going to be (in order of preference):
1. Get approval from TM about continued use of the fluo.io domain as an
unaffiliated community site.
2. Choose a new name for the podling project.
3. Your recommendation above.
Thanks for the good discussion. This has helped raise a lot of issues we
hadn't previously considered, and helped clarify what we need to do next.
I'm optimistic that the end result will be a clear path forward which
serves the community well.
Should I CC this list for the trademarks@ list discussion? Or just provide
a lists.apache.org link?
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Aug 1, 2016 at 8:08 PM, John D. Ament <jo...@apache.org> wrote:
> Ok, now I'm a bit confused. I'll try my best to state my points of
> clarification in line.
>
> On Mon, Aug 1, 2016 at 7:37 PM Christopher <ct...@apache.org> wrote:
>
>> I also wish to point out that the FluoProposal (
>> http://wiki.apache.org/incubator/FluoProposal) explicitly included an
>> intent/wish/request to continue using the Fluo logo (which includes the
>> name) on Fluo's historical sites. That proposal was accepted by the IPMC
>>
>
> I'm confused what this has to do with a logo. I see now in your proposal
> that there's an explicit call out for the logo. I'm not sure why. Its a
> nice logo. Assuming it was donated as a part of the overall donation, then
> there's no issue reusing it on other sites.
>
>
>> (albeit without an explicit judgment on that issue). While the proposal did
>> not explicitly mention the domain name concerns, it did mention the
>> continued existence of "historical sites" after acceptance, sites whose
>> names could reasonably be expected to contain the Fluo name. I think this
>> is important in determining to what extent it should be considered fair and
>> reasonable to use the word "Fluo" on "fluo.io".
>>
>
> The term "historical" is used in the proposal. My interpretation of its
> use is that some sites may exist for historical purposes. It seems that
> the intention however is to keep them going. The list of sites are not
> mentioned, other than a GitHub site, which I'm not sure if that means
> fluo.github.io, github.com/fluo-io, or something else. Its not obvious to
> me that this is fluo.io which may be hosted as a github pages website.
>
>
>>
>> At no point in the proposal or vote discussions for Fluo was it mentioned
>> that we'd have to remove or transfer control of the fluo.io domain, in
>> order to be compliant with ASF trademark policies upon acceptance into
>> Incubator, even though it was clear at the time that 1) the domain existed
>> and 2) hosted projects which would transfer to the ASF and projects which
>> would not.
>>
>
> The proposal is a bit missing in this area. I see a documentation section,
> which mentions the website fluo.io. Ignoring this discussion, my
> interpretation of this section is that it was being donated. Yes,
> transference of domain names is expected. Many projects coming in have
> done this (groovy-lang.org, freemarker.org are some examples). If it was
> not intended to be transferred, its not clear to me why its mentioned in
> the proposal.
>
>
>
>>
>> Taking this into account, and in conjunction with our intent to fix both
>> websites to reduce confusion, I hope that we can find a resolution which
>> does not require a name change, but can leave both fluo.apache.org and
>> fluo.io coexisting.
>>
>>
> The co-existing part is where you need to talk more to TM and get their buy
> in. Right now we have a highly inconsistent model at the ASF.
>
>
>> I think our immediate, actionable plan should be to:
>>
>> 1. Remove redirect from fluo.io to fluo.apache.org
>
>
> I'm not sure if you're doing this out of anger or what. The current setup
> of redirect is fine.
>
>
>>
>> 2. Place content on fluo.io which:
>> 2.a) links to Apache Fluo
>> 2.b) states that Fluo is a trademark of Apache
>> 2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
>> 2.d) is primarily focused on the community tools it hosts, and not Apache
>> Fluo
>
> 3. Ensure content on fluo.apache.org is updated to:
>> 3.a) remove pre-apache release or clearly document them.
>> 3.b) remove any implication that Fluo depends on any software at fluo.io
>> 3.c) ensure no dependency on external documentation at fluo.io
>
>
> All of the items under 3 are great graduation goals, and are not needed in
> the short term.
>
>
>>
>> 4. Standardize on a different publicly available checkstyle and formatter
>> ruleset than the io.fluo:resources ones (maybe?)
>>
>
> Just to be clear. my concern here is shared with the domain name. If the
> domain name is cleared to be used, I don't have a strong concern on this.
>
>
>>
>> If we're going to expend this effort, it would be nice to get some
>> assurances that this will be sufficient to resolve branding concerns, or if
>> there are additional steps short of changing the domain names, which we can
>> take to resolve these issues.
>>
>
>
> My recommendation is that fluo.io be donated to the ASF and a new domain
> name chosen for the non-ASF community backed site.
When you say donate it to the ASF, I am assumimg you intend that
fluo.io and fluo.apache.org both serve the same content. Or were you
thinking of something else?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
Ok, now I'm a bit confused. I'll try my best to state my points of
clarification in line.
On Mon, Aug 1, 2016 at 7:37 PM Christopher <ct...@apache.org> wrote:
> I also wish to point out that the FluoProposal (
> http://wiki.apache.org/incubator/FluoProposal) explicitly included an
> intent/wish/request to continue using the Fluo logo (which includes the
> name) on Fluo's historical sites. That proposal was accepted by the IPMC
>
I'm confused what this has to do with a logo. I see now in your proposal
that there's an explicit call out for the logo. I'm not sure why. Its a
nice logo. Assuming it was donated as a part of the overall donation, then
there's no issue reusing it on other sites.
> (albeit without an explicit judgment on that issue). While the proposal did
> not explicitly mention the domain name concerns, it did mention the
> continued existence of "historical sites" after acceptance, sites whose
> names could reasonably be expected to contain the Fluo name. I think this
> is important in determining to what extent it should be considered fair and
> reasonable to use the word "Fluo" on "fluo.io".
>
The term "historical" is used in the proposal. My interpretation of its
use is that some sites may exist for historical purposes. It seems that
the intention however is to keep them going. The list of sites are not
mentioned, other than a GitHub site, which I'm not sure if that means
fluo.github.io, github.com/fluo-io, or something else. Its not obvious to
me that this is fluo.io which may be hosted as a github pages website.
>
> At no point in the proposal or vote discussions for Fluo was it mentioned
> that we'd have to remove or transfer control of the fluo.io domain, in
> order to be compliant with ASF trademark policies upon acceptance into
> Incubator, even though it was clear at the time that 1) the domain existed
> and 2) hosted projects which would transfer to the ASF and projects which
> would not.
>
The proposal is a bit missing in this area. I see a documentation section,
which mentions the website fluo.io. Ignoring this discussion, my
interpretation of this section is that it was being donated. Yes,
transference of domain names is expected. Many projects coming in have
done this (groovy-lang.org, freemarker.org are some examples). If it was
not intended to be transferred, its not clear to me why its mentioned in
the proposal.
>
> Taking this into account, and in conjunction with our intent to fix both
> websites to reduce confusion, I hope that we can find a resolution which
> does not require a name change, but can leave both fluo.apache.org and
> fluo.io coexisting.
>
>
The co-existing part is where you need to talk more to TM and get their buy
in. Right now we have a highly inconsistent model at the ASF.
> I think our immediate, actionable plan should be to:
>
> 1. Remove redirect from fluo.io to fluo.apache.org
I'm not sure if you're doing this out of anger or what. The current setup
of redirect is fine.
>
> 2. Place content on fluo.io which:
> 2.a) links to Apache Fluo
> 2.b) states that Fluo is a trademark of Apache
> 2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
> 2.d) is primarily focused on the community tools it hosts, and not Apache
> Fluo
3. Ensure content on fluo.apache.org is updated to:
> 3.a) remove pre-apache release or clearly document them.
> 3.b) remove any implication that Fluo depends on any software at fluo.io
> 3.c) ensure no dependency on external documentation at fluo.io
All of the items under 3 are great graduation goals, and are not needed in
the short term.
>
> 4. Standardize on a different publicly available checkstyle and formatter
> ruleset than the io.fluo:resources ones (maybe?)
>
Just to be clear. my concern here is shared with the domain name. If the
domain name is cleared to be used, I don't have a strong concern on this.
>
> If we're going to expend this effort, it would be nice to get some
> assurances that this will be sufficient to resolve branding concerns, or if
> there are additional steps short of changing the domain names, which we can
> take to resolve these issues.
>
My recommendation is that fluo.io be donated to the ASF and a new domain
name chosen for the non-ASF community backed site.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
I also wish to point out that the FluoProposal (
http://wiki.apache.org/incubator/FluoProposal) explicitly included an
intent/wish/request to continue using the Fluo logo (which includes the
name) on Fluo's historical sites. That proposal was accepted by the IPMC
(albeit without an explicit judgment on that issue). While the proposal did
not explicitly mention the domain name concerns, it did mention the
continued existence of "historical sites" after acceptance, sites whose
names could reasonably be expected to contain the Fluo name. I think this
is important in determining to what extent it should be considered fair and
reasonable to use the word "Fluo" on "fluo.io".
At no point in the proposal or vote discussions for Fluo was it mentioned
that we'd have to remove or transfer control of the fluo.io domain, in
order to be compliant with ASF trademark policies upon acceptance into
Incubator, even though it was clear at the time that 1) the domain existed
and 2) hosted projects which would transfer to the ASF and projects which
would not.
Taking this into account, and in conjunction with our intent to fix both
websites to reduce confusion, I hope that we can find a resolution which
does not require a name change, but can leave both fluo.apache.org and
fluo.io coexisting.
I think our immediate, actionable plan should be to:
1. Remove redirect from fluo.io to fluo.apache.org
2. Place content on fluo.io which:
2.a) links to Apache Fluo
2.b) states that Fluo is a trademark of Apache
2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
2.d) is primarily focused on the community tools it hosts, and not Apache
Fluo
3. Ensure content on fluo.apache.org is updated to:
3.a) remove pre-apache release or clearly document them.
3.b) remove any implication that Fluo depends on any software at fluo.io
3.c) ensure no dependency on external documentation at fluo.io
4. Standardize on a different publicly available checkstyle and formatter
ruleset than the io.fluo:resources ones (maybe?)
If we're going to expend this effort, it would be nice to get some
assurances that this will be sufficient to resolve branding concerns, or if
there are additional steps short of changing the domain names, which we can
take to resolve these issues.
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The question of trademarks and groupIds has come up before (
> https://lists.apache.org/thread.html/24c6270458faf64da351027cde5c74e935d6b5760b511b4e2f0c6b98@1388455319@%3Cprivate.accumulo.apache.org%3E),
> but in those circumstances, the conflict was much more direct (reuse of the
> "org.apache.*" groupId in maven artifacts). I would think that the
> "io.fluo" groupId would clearly indicate this is a separate organization,
> clearly distinct from Apache. If the simple reuse of the word "fluo" is
> enough to trigger a branding issue
It can be.
> , then I would imagine things like "maven-checkstyle-plugin" reusing the word "checkstyle" while it depends on
> a 3rd party "checkstyle" artifact would be similarly concerning
No they are not as maven has a long history of working this way so it easily understood what’s Apache and what isn’t. This is pointed out in on one of the trademark policy pages.
> Further, there's lots
> of third party websites which have ASF project names in their domain name,
> twitter handles, etc...
If there are that’s issue and they should be looked into, for domain names policy see [1].
Thanks,
Justin
1. http://www.apache.org/foundation/marks/domains.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 1, 2016 at 9:37 AM John D. Ament <jo...@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.
>
fluo-dev and zetten are supplemental community projects that build on fluo,
to make it easier to use and test. These are the kind of community
extensions we want to encourage around Apache projects, I would think. We
can probably do a better job highlighting these community efforts as
external to ASF, but it'd be a shame if we weren't allowed to link to
them... as they are useful third party efforts which benefit the Apache
Fluo project's community.
> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
> within your pom files. Its still not clear to me why your parent declares
> dependencies on previously released artifacts and why those can't be
> bundled within the release.
>
>
It's not a previously released version of anything which now exists in ASF.
It's just a jar containing some checkstyle and formatter rules we'd like to
use. These rules are non-specific to Fluo, but which happened to be
released under the io.fluo groupId in Maven. Moving these rules over to the
ASF to perform a release of them under the Apache brand would add no value.
The artifactId doesn't even contain "fluo"... just the groupId, which
indicates the entity of its origins, and it's simply a fact that it came
from the "fluo.io" domain ("io.fluo" groupId). I'm not sure it would be
appropriate to transition it to ASF and release it under the Apache brand
simply to conceal this fact.
The question of trademarks and groupIds has come up before (
https://lists.apache.org/thread.html/24c6270458faf64da351027cde5c74e935d6b5760b511b4e2f0c6b98@1388455319@%3Cprivate.accumulo.apache.org%3E),
but in those circumstances, the conflict was much more direct (reuse of the
"org.apache.*" groupId in maven artifacts). I would think that the
"io.fluo" groupId would clearly indicate this is a separate organization,
clearly distinct from Apache. If the simple reuse of the word "fluo" is
enough to trigger a branding issue, then I would imagine things like
"maven-checkstyle-plugin" reusing the word "checkstyle" while it depends on
a 3rd party "checkstyle" artifact would be similarly concerning, as would
all of the 3rd party "X-maven-plugin" artifacts out there which reuse the
brand "maven", even though they aren't ASF projects. Further, there's lots
of third party websites which have ASF project names in their domain name,
twitter handles, etc... and these don't usually raise branding concerns so
long as they aren't misrepresenting themselves as part of, or endorsed by,
the ASF.
> John
>
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
Legacy release issues look better.
On Mon, Aug 1, 2016 at 11:38 AM Mike Walch <mw...@apache.org> wrote:
> Thanks for reviewing the Fluo website. I created a pull request to fix
> some of the issues you brought up.
>
> https://github.com/apache/incubator-fluo-website/pull/9
>
> Does this address your concerns? Feel free to comment/review the pull
> request on GitHub.
>
> On Mon, Aug 1, 2016 at 9:37 AM John D. Ament <jo...@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.
> > - Make sure that io.fluo is either replaced, or has a ticket to be
> replaced
> > within your pom files. Its still not clear to me why your parent
> declares
> > dependencies on previously released artifacts and why those can't be
> > bundled within the release.
> >
> > John
> >
> > On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
> >
> > > io.fluo was the groupId for Fluo before it transitioned to incubation.
> > This
> > > parent POM references a previously released (prior to acceptance into
> > > incubation) resources artifact under that identity, which contains
> > > checkstyle and Eclipse code formatter rules which this project still
> uses
> > > to apply consistent formatting and style checks to maven projects using
> > > this parent POM.
> > >
> > > On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
> > > wrote:
> > >
> > > > What is io.fluo and why does this depend on it? Sounds like a
> branding
> > > > issue.
> > > >
> > > > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
> > > >
> > > > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo
> team
> > is
> > > > > first separately releasing a parent POM. This release passed a PPMC
> > > vote
> > > > on
> > > > > the Fluo dev@ list here:
> > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
> > > > >
> > > > > Please consider the following candidate for Fluo Parent POM
> > > 1-incubating.
> > > > >
> > > > > Git Commit:
> > > > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> > > > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > > > > Branch:
> > > > > fluo-parent-1-rc2
> > > > >
> > > > > If this vote passes, a gpg-signed tag will be created using:
> > > > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> > > > > rel/fluo-parent-1-incubating
> e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > > > >
> > > > > Staging repo:
> > > > >
> > https://repository.apache.org/content/repositories/orgapachefluo-1003
> > > > > Source (official release artifact):
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> > > > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash
> > for a
> > > > > given artifact.)
> > > > >
> > > > > Signing key fingerprint is:
> 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> > > > >
> > > > > Please vote one of:
> > > > > [ ] +1 - I have verified and accept...
> > > > > [ ] +0 - I have reservations, but not strong enough to vote
> > against...
> > > > > [ ] -1 - Because..., I do not accept...
> > > > > ... these artifacts as the 1-incubating release of Apache Fluo
> Parent
> > > > POM.
> > > > >
> > > > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
> > > > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
> > > > >
> > > > > Thanks!
> > > > >
> > > > > P.S. Hint: download the whole staging repo with
> > > > > wget -erobots=off -r -l inf -np -nH \
> > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/
> > > > > # note the trailing slash is needed
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Mike Walch <mw...@apache.org>.
Thanks for reviewing the Fluo website. I created a pull request to fix
some of the issues you brought up.
https://github.com/apache/incubator-fluo-website/pull/9
Does this address your concerns? Feel free to comment/review the pull
request on GitHub.
On Mon, Aug 1, 2016 at 9:37 AM John D. Ament <jo...@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.
> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
> within your pom files. Its still not clear to me why your parent declares
> dependencies on previously released artifacts and why those can't be
> bundled within the release.
>
> John
>
> On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
>
> > io.fluo was the groupId for Fluo before it transitioned to incubation.
> This
> > parent POM references a previously released (prior to acceptance into
> > incubation) resources artifact under that identity, which contains
> > checkstyle and Eclipse code formatter rules which this project still uses
> > to apply consistent formatting and style checks to maven projects using
> > this parent POM.
> >
> > On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
> > wrote:
> >
> > > What is io.fluo and why does this depend on it? Sounds like a branding
> > > issue.
> > >
> > > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
> > >
> > > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team
> is
> > > > first separately releasing a parent POM. This release passed a PPMC
> > vote
> > > on
> > > > the Fluo dev@ list here:
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
> > > >
> > > > Please consider the following candidate for Fluo Parent POM
> > 1-incubating.
> > > >
> > > > Git Commit:
> > > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> > > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > > > Branch:
> > > > fluo-parent-1-rc2
> > > >
> > > > If this vote passes, a gpg-signed tag will be created using:
> > > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> > > > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > > >
> > > > Staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachefluo-1003
> > > > Source (official release artifact):
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> > > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash
> for a
> > > > given artifact.)
> > > >
> > > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> > > >
> > > > Please vote one of:
> > > > [ ] +1 - I have verified and accept...
> > > > [ ] +0 - I have reservations, but not strong enough to vote
> against...
> > > > [ ] -1 - Because..., I do not accept...
> > > > ... these artifacts as the 1-incubating release of Apache Fluo Parent
> > > POM.
> > > >
> > > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
> > > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
> > > >
> > > > Thanks!
> > > >
> > > > P.S. Hint: download the whole staging repo with
> > > > wget -erobots=off -r -l inf -np -nH \
> > > >
> > > https://repository.apache.org/content/repositories/orgapachefluo-1003/
> > > > # note the trailing slash is needed
> > > >
> > >
> >
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
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.
- Make sure that io.fluo is either replaced, or has a ticket to be replaced
within your pom files. Its still not clear to me why your parent declares
dependencies on previously released artifacts and why those can't be
bundled within the release.
John
On Sat, Jul 30, 2016 at 2:33 PM Christopher <ct...@apache.org> wrote:
> io.fluo was the groupId for Fluo before it transitioned to incubation. This
> parent POM references a previously released (prior to acceptance into
> incubation) resources artifact under that identity, which contains
> checkstyle and Eclipse code formatter rules which this project still uses
> to apply consistent formatting and style checks to maven projects using
> this parent POM.
>
> On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org>
> wrote:
>
> > What is io.fluo and why does this depend on it? Sounds like a branding
> > issue.
> >
> > On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
> >
> > > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
> > > first separately releasing a parent POM. This release passed a PPMC
> vote
> > on
> > > the Fluo dev@ list here:
> > >
> > >
> >
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
> > >
> > > Please consider the following candidate for Fluo Parent POM
> 1-incubating.
> > >
> > > Git Commit:
> > > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> > > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > > Branch:
> > > fluo-parent-1-rc2
> > >
> > > If this vote passes, a gpg-signed tag will be created using:
> > > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> > > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapachefluo-1003
> > > Source (official release artifact):
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> > > given artifact.)
> > >
> > > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> > >
> > > Please vote one of:
> > > [ ] +1 - I have verified and accept...
> > > [ ] +0 - I have reservations, but not strong enough to vote against...
> > > [ ] -1 - Because..., I do not accept...
> > > ... these artifacts as the 1-incubating release of Apache Fluo Parent
> > POM.
> > >
> > > This vote will end on Tue Aug 02 18:30:00 UTC 2016
> > > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
> > >
> > > Thanks!
> > >
> > > P.S. Hint: download the whole staging repo with
> > > wget -erobots=off -r -l inf -np -nH \
> > >
> > https://repository.apache.org/content/repositories/orgapachefluo-1003/
> > > # note the trailing slash is needed
> > >
> >
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
io.fluo was the groupId for Fluo before it transitioned to incubation. This
parent POM references a previously released (prior to acceptance into
incubation) resources artifact under that identity, which contains
checkstyle and Eclipse code formatter rules which this project still uses
to apply consistent formatting and style checks to maven projects using
this parent POM.
On Sat, Jul 30, 2016 at 2:24 PM John D. Ament <jo...@apache.org> wrote:
> What is io.fluo and why does this depend on it? Sounds like a branding
> issue.
>
> On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
>
> > In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
> > first separately releasing a parent POM. This release passed a PPMC vote
> on
> > the Fluo dev@ list here:
> >
> >
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
> >
> > Please consider the following candidate for Fluo Parent POM 1-incubating.
> >
> > Git Commit:
> > (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > Branch:
> > fluo-parent-1-rc2
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> > rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1003
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> > given artifact.)
> >
> > Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> >
> > Please vote one of:
> > [ ] +1 - I have verified and accept...
> > [ ] +0 - I have reservations, but not strong enough to vote against...
> > [ ] -1 - Because..., I do not accept...
> > ... these artifacts as the 1-incubating release of Apache Fluo Parent
> POM.
> >
> > This vote will end on Tue Aug 02 18:30:00 UTC 2016
> > (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
> >
> > Thanks!
> >
> > P.S. Hint: download the whole staging repo with
> > wget -erobots=off -r -l inf -np -nH \
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/
> > # note the trailing slash is needed
> >
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by "John D. Ament" <jo...@apache.org>.
What is io.fluo and why does this depend on it? Sounds like a branding
issue.
On Jul 30, 2016 14:14, "Christopher" <ct...@apache.org> wrote:
> In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
> first separately releasing a parent POM. This release passed a PPMC vote on
> the Fluo dev@ list here:
>
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
>
> Please consider the following candidate for Fluo Parent POM 1-incubating.
>
> Git Commit:
> (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> e9ed4334dd4cc5df27def417f26d6d7362470cb8
> Branch:
> fluo-parent-1-rc2
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachefluo-1003
> Source (official release artifact):
>
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>
> Please vote one of:
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1-incubating release of Apache Fluo Parent POM.
>
> This vote will end on Tue Aug 02 18:30:00 UTC 2016
> (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
>
> Thanks!
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH \
> https://repository.apache.org/content/repositories/orgapachefluo-1003/
> # note the trailing slash is needed
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Keith Turner <ke...@deenlo.com>.
On Sat, Jul 30, 2016 at 10:51 PM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
> Looking a bit further the the Apache Fluo web site I see a couple of concerning things, but presumably this is part of a ongoing effort and will be sorted out before graduation:
> - It seems the main source of distribution is github [1][2] and Sonatype [2] not the Apache mirrors.
> - There are links to unapproved releases in these places [1][3][5][6]. This can be fixed by making it clear that these are not Apache releases.
> - There are several branding issues. For instance Fluo should be referred to as “Apache Fluo”, please review the branding guidelines. [4] I can see it's done a couple of times on the first page, but other pages like docs, downloads and release process page do not make this entirely clear this is an Apache project.
>
> Thanks,
> Justin
Thanks for reviewing the web site.
>
> 1. https://fluo.apache.org/download/
> 2. https://fluo.apache.org/release-process/
> 3. https://fluo.apache.org/docs/
> 4. http://www.apache.org/foundation/marks/pmcs.html
> 5. https://github.com/apache/incubator-fluo/releases/tag/1.0.0-beta-2
> 6. https://github.com/apache/incubator-fluo/releases
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Sat, Jul 30, 2016 at 10:52 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Looking a bit further the the Apache Fluo web site I see a couple of
> concerning things, but presumably this is part of a ongoing effort and will
> be sorted out before graduation:
> - It seems the main source of distribution is github [1][2] and Sonatype
> [2] not the Apache mirrors.
> - There are links to unapproved releases in these places [1][3][5][6].
> This can be fixed by making it clear that these are not Apache releases.
> - There are several branding issues. For instance Fluo should be referred
> to as “Apache Fluo”, please review the branding guidelines. [4] I can see
> it's done a couple of times on the first page, but other pages like docs,
> downloads and release process page do not make this entirely clear this is
> an Apache project.
>
>
Again, thanks for looking at this. The website is definitely an ongoing
effort, which we hope will sort out before graduation. Your eyes on this is
very helpful to that end. Hopefully the site's disclaimer about being under
incubation serves the purpose of indicating the potential for problems and
inconsistencies, in the interim.
Perhaps we can address those issues in a separate thread from this one, so
as not to further clutter the consideration of this particular
release/vote? (Unless you think they are interrelated and should be
addressed concurrently, in which case, we can continue to address them
inline with this thread.)
Thanks again for giving us a thorough examination. We'll do our best to
work through those issues you've identified so far over the upcoming week.
> Thanks,
> Justin
>
> 1. https://fluo.apache.org/download/
> 2. https://fluo.apache.org/release-process/
> 3. https://fluo.apache.org/docs/
> 4. http://www.apache.org/foundation/marks/pmcs.html
> 5. https://github.com/apache/incubator-fluo/releases/tag/1.0.0-beta-2
> 6. https://github.com/apache/incubator-fluo/releases
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Looking a bit further the the Apache Fluo web site I see a couple of concerning things, but presumably this is part of a ongoing effort and will be sorted out before graduation:
- It seems the main source of distribution is github [1][2] and Sonatype [2] not the Apache mirrors.
- There are links to unapproved releases in these places [1][3][5][6]. This can be fixed by making it clear that these are not Apache releases.
- There are several branding issues. For instance Fluo should be referred to as “Apache Fluo”, please review the branding guidelines. [4] I can see it's done a couple of times on the first page, but other pages like docs, downloads and release process page do not make this entirely clear this is an Apache project.
Thanks,
Justin
1. https://fluo.apache.org/download/
2. https://fluo.apache.org/release-process/
3. https://fluo.apache.org/docs/
4. http://www.apache.org/foundation/marks/pmcs.html
5. https://github.com/apache/incubator-fluo/releases/tag/1.0.0-beta-2
6. https://github.com/apache/incubator-fluo/releases
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It's not released yet. It was my understanding that we don't put stuff
> there until the vote actually passes a vote for a release, and for that we
> need the IPMC to vote after the PPMC votes
You put stuff into the dev area after a release has been approved but before that it needs to go in the /dist/dev. That way you can easily release exactly what was voted on.
> It's just a Maven parent POM. There isn't any code. Just a POM, which is an
> XML file.
Seem odd to have a release with no code but I guess that that’s allowed.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
On Sat, Jul 30, 2016 at 9:55 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1003
> > Source (official release artifact):
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
>
> I’m a little confused as to what we are voting on here as:
> 1. This is no release in the offical area [1][2]
>
It's not released yet. It was my understanding that we don't put stuff
there until the vote actually passes a vote for a release, and for that we
need the IPMC to vote after the PPMC votes.
> 2. There is no code in the above release, is this intentional or is
> something missing?
>
>
It's just a Maven parent POM. There isn't any code. Just a POM, which is an
XML file. We did this as a separate release for two reasons:
1) to exercise the incubator release process (we've never done an incubator
release before), and
2) so we can use the released POM as our parent POM for the actual Fluo
release. In order for that to happen, it would be useful to be able to push
this POM out to Maven Central, so maven can resolve it when building our
main artifacts with Jenkins and for the upcoming release candidates (Fluo
1.0.0-incubating, which we're getting ready for).
So, yes, lack of code is intentional. The vote is on the parent POM, which
we've built as a separate artifact.
> Thanks,
> Justin
>
> 1. https://dist.apache.org/repos/dist/dev/incubator/
> 2.incubator apache https://dist.apache.org/repos/dist/dev/incubator/
>
>
Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachefluo-1003
> Source (official release artifact):
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
I’m a little confused as to what we are voting on here as:
1. This is no release in the offical area [1][2]
2. There is no code in the above release, is this intentional or is something missing?
Thanks,
Justin
1. https://dist.apache.org/repos/dist/dev/incubator/
2.incubator apache https://dist.apache.org/repos/dist/dev/incubator/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[CANCEL][VOTE] Fluo Parent POM 1-incubating (rc2)
Posted by Christopher <ct...@apache.org>.
Consider this vote canceled, until we can work through some of the issues
identified in the thread.
On Sat, Jul 30, 2016 at 2:14 PM Christopher <ct...@apache.org> wrote:
> In preparation for a 1.0.0-incubating release of Fluo, the Fluo team is
> first separately releasing a parent POM. This release passed a PPMC vote on
> the Fluo dev@ list here:
> https://lists.apache.org/thread.html/2f801cc81b7eab1f3438da23d8973626755a77e9038f80cce2b30ae9@%3Cdev.fluo.apache.org%3E
>
> Please consider the following candidate for Fluo Parent POM 1-incubating.
>
> Git Commit:
> (https://git-wip-us.apache.org/repos/asf/incubator-fluo.git)
> e9ed4334dd4cc5df27def417f26d6d7362470cb8
> Branch:
> fluo-parent-1-rc2
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> rel/fluo-parent-1-incubating e9ed4334dd4cc5df27def417f26d6d7362470cb8
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachefluo-1003
> Source (official release artifact):
> https://repository.apache.org/content/repositories/orgapachefluo-1003/org/apache/fluo/fluo-parent/1-incubating/fluo-parent-1-incubating-source-release.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> Signing key fingerprint is: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>
> Please vote one of:
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1-incubating release of Apache Fluo Parent POM.
>
> This vote will end on Tue Aug 02 18:30:00 UTC 2016
> (Tue Aug 02 14:30:00 EDT 2016 / Tue Aug 02 11:30:00 PDT 2016)
>
> Thanks!
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH \
> https://repository.apache.org/content/repositories/orgapachefluo-1003/
> # note the trailing slash is needed
>
>