Re: What is the legal basis for enforcing release policies at ASF?

[Christopher]

It sounds to me like you're saying that the license under which code is
offered (to anybody who encounters it) is independent of the license
declaration attached to the project.

This makes sense to me, presuming that we still agree that the license
declaration (header or license file) is the best way to communicate the
license under which the code is offered.

It seems to follow, then, that were saying that there are sometimes errors
in the declaration, where it doesn't reflect what license the code is
actually offered under (if any). Further, we're saying that this is
hopefully less likely in a release, which has been vetted with greater
scrutiny.

Is that right?

If so, then it seems to me that the question really becomes: is it
sufficiently communicated by the very fact of being a snapshot (any state
of the code other than in a release), that errors are possible in the
license? I would think the answer is yes, personally. However, I'm not sure
it really means much, because it's still reasonable for people to assume
the license declaration is correct, until shown otherwise.

It seems to me that the very fact that any license declaration is attached
to the code at all, regardless of its state as a release or snapshot,
shifts the burden of responsibility to actually demonstrate that the
license does not apply. This is the reverse of the case when no obvious
license declaration is made. The burden in that case is to show that the
license does apply. Isn't that why we explicitly put headers on each file,
in addition to the LICENSE file? To explicitly shift this burden to us in
order to encourage free use of our software by others?

On Thu, Aug 20, 2015, 21:19 William A Rowe Jr  wrote:

> On Aug 20, 2015 7:39 PM, "Alex Harui"  wrote:
> >
> >
> >
> > On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:
> >
> > >It is generally AL code all the time.  I don't know where you invented a
> > >'kick-in' concept, but unless the committers are violating their
> > >ICLA/CCLA,
> > >nothing could be further from the truth.
> >
> > Committers sometimes make mistakes.  IIRC, Justin recently caught a
> > mistake where some files accidentally got their non-AL headers replaced
> > with AL headers.
> >
> > Large codebase contributions, especially initial podling code grants
> might
> > be messy as well until scrubbed and approved for an official ASF release.
> > I know from experience.
>
> We don't disagree on this point.  Sometimes, they are caught through the
> release process, or by peer review.  Other times, we must retract the claim
> we offered.
>
> Nothing changes the fact that code is either offered under the AL 2.0 or
> another license, unless the author/licensor changes their license
> retroactively.
>

Re: Making license adjustment tools publicly available

[Christopher]

It might be relevant that that both of those tools appear to be licensed
under ASL 2.0, which explicitly permits redistribution (presumably outside
the private area?). I would think it confusing to have an open source
license on software which is expected to remain private, or otherwise
restricted from redistribution. As such, it seems prudent to move them to a
more appropriate area. That's my opinion, anyway.

On Thu, Feb 4, 2016 at 7:14 PM Roman Shaposhnik  wrote:

> Hi!
>
> a podling recently asked me why:
> https://svn.apache.org/repos/private/committers/relicense/
> https://svn.apache.org/repos/private/committers/tools/copy2license.pl
> are only available to commiters. I see
> no reason why, but of course I'm appreciative
> of the warning here:
> https://svn.apache.org/repos/private/committers/README
>
> Two questions:
>1. Is there any disagreement that making this tool publically
> available would be a 'good thing' ?
> 2. Who should bless the svn mv if we all agree?
>
> Thanks,
> Roman.
>

Incubator Lists

[Christopher]

Hi all,

I'm just getting familiar with the incubator project, because I am
anticipating working with some future projects which might submit proposals
to go through incubation, and I'd like to gain some greater familiarity
with how things operate in this space. I've already started reading through
all the stuff linked on the incubator site, and I've subscribed to this
list.

Are there any other lists or areas of collaboration (JIRA, etc.) I should
know about, in order to get more involved, or is this the main incubator
list where most things get discussed for projects going through the process?

The Apache Way incubator page

[Christopher]

The page at
http://incubator.apache.org/learn/theapacheway.html

needs to be updated to reflect the new location of the ComDev mailing
lists. It is no longer commun...@apache.org (and
community-subscr...@apache.org), but is instead d...@community.apache.org
(and dev-subscr...@community.apache.org).

Request for Incubator Wiki Access

[Christopher]

Can I get edit access to the Wiki?

Username: ChristopherTubbs

Re: Request for Incubator Wiki Access

[Christopher]

Thanks!

On Tue, Apr 19, 2016 at 12:15 PM Nick Burch  wrote:

> On Tue, 19 Apr 2016, Christopher wrote:
> > Can I get edit access to the Wiki?
> >
> > Username: ChristopherTubbs
>
> Karma granted, enjoy editing!
>
> Nick
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[PROPOSAL] Fluo

[Christopher]

che Brand ===

While we recognize the impact of the Apache brand, we feel that Fluo would
fit well in Apache because of its relationship to other Apache projects and
because we share the ASF values of meritocracy and community over code.

== Documentation ==

Information about Fluo can be found on the project website at
http://fluo.io/. This includes:

 * General documentation - http://fluo.io/docs/
 * API documentation - http://fluo.io/apidocs/
 * Release notes - http://fluo.io/release-notes/
 * Blog posts - http://fluo.io/blog/

== Initial Source ==

The initial source code is publicly available as an open source project on
GitHub at https://github.com/fluo-io/fluo

Supplemental repositories also exist on GitHub at https://github.com/fluo-io
and some of those will become part of the initial code base (perhaps in
separate repositories).

== Source and Intellectual Property Submission Plan ==

All of the Fluo’s source code is available under the Apache License,
Version 2.

The Fluo logo was designed and contributed to the Fluo project, for use by
the project, and the contributors would like it to remain the logo of the
project within the ASF, granting any necessary rights to the ASF, while
continuing to use the logo on Fluo-related historical sites and project
pages (such as Fluo’s current GitHub site).

== External Dependencies ==

Fluo has made it a point from its beginning to use dependencies which are
compatible with the expectations of an ASF project. The following are its
current dependencies, grouped by license.

Apache License, Version 2.0
 * accumulo
 * commons-{collections,configuration,io}
 * curator
 * dropwizard metrics
 * easymock
 * guava
 * hadoop
 * jcommander
 * maven
 * thrift
 * twill
 * zookeeper

BSD License (2-Clause)
 * HdrHistogram

Eclipse Public License - v 1.0
 * junit (not bundled)
 * logback (binary bundling only)

MIT License (Expat)
 * slf4j

== Cryptography ==

none

== Required Resources ==

=== Mailing Lists ===

   * private at fluo.incubator.apache.org
   * dev at fluo.incubator.apache.org
   * notifications at fluo.incubator.apache.org

=== Git Repository ===

   * https://git-wip-us.apache.org/repos/asf/incubator-fluo.git
 (The developers will use a git-based site for project documentation in
the ''asf-site'' branch of the repo.)
   * https://git-wip-us.apache.org/repos/asf/incubator-fluo-recipes.git

=== Issue Tracking ===

   * https://issues.apache.org/jira/browse/FLUO
 (Currently, the developers rely on GitHub issues. If possible, GitHub
integration for issue tracking would be preferred. If this is possible, the
Fluo developers could work with INFRA to transfer the existing GitHub
repositories to the Apache GitHub organization to bring the existing GitHub
issues.)

=== Continuous Integration ===

   * Travis CI on the GitHub mirror is fine (flag set to build only if
''.travis.yml'' file is present)

== Initial Committers ==

 * Keith Turner (kturner at apache dot org)
 * Mike Walch (mike.walch at ptech-llc dot com)
 * Corey Nolet (cjnolet at apache dot org)
 * Christopher Tubbs (ctubbsii at apache dot org)
 * Josh Elser (elserj at apache dot org)

== Affiliations ==

 * Keith Turner (Peterson Technologies, ASF Member, Accumulo PMC, Gora PMC)
 * Mike Walch (Peterson Technologies)
 * Corey Nolet (Tetra Concepts LLC, Accumulo PMC)
 * Christopher Tubbs (U.S. Government, ASF Member, Accumulo PMC)
 * Josh Elser (Hortonworks, ASF Member, Accumulo PMC, Calcite PMC, IPMC)

== Sponsors ==

=== Champion ===

 * Billie Rinaldi (billie at apache dot org) has volunteered to be our
Champion

=== Nominated Mentors ===

 * Billie Rinaldi (billie at apache dot org)
 * Benson Margulies (bimargulies at apache dot org)
 * Lewis John McGibbney (lewiscmc at apache dot org)
 * Chris Mattmann (mattmann at apache dot org)

=== Sponsoring Entity ===

 * The Fluo team requests sponsorship from the Incubator PMC

Re: [PROPOSAL] Fluo

[Christopher]

On Fri, Apr 29, 2016 at 9:04 AM Edward Capriolo 
wrote:

> I would suggest, my feeling is that tools that work with more than one
> nosql have a better chance at success. Are there plans for hbase/Cassandra
> support?
>
>

To directly answer the question, no, there are no current plans for
supporting those with Fluo.

That said, we (Fluo developers) have discussed this possibility, and would
welcome contributions which do extend support to those, and possibly other
systems. Fluo's API is largely agnostic to the underlying system, so it
could be possible in theory. However, it would be a huge effort that the
current developers are not prepared for. That could be easier if there
existed a common API which supported each of these systems. I don't know
that any such system exists today, and certainly not one which exposes some
of the key features which Fluo needs to run (ConditionalMutations and
custom use of the versioning timestamp bits with specialized iterators, for
example).

Re: [PROPOSAL] Fluo

[Christopher]

On Tue, Apr 19, 2016 at 1:21 PM Christopher  wrote:

> For the incubator consideration, the Fluo developers submit the following
> proposal:
> https://wiki.apache.org/incubator/FluoProposal
>
> = Fluo Proposal =
>
> == Abstract ==
>
> Fluo is a distributed system for incrementally processing large data sets
> stored in Accumulo.
>
> == Proposal ==
>
> Fluo is a distributed transaction and notification system that enables the
> incremental processing of large data sets. Its transaction system allows
> for concurrent, cross-node updates to data stored in Accumulo. Its
> notification system enables developers to write code to be executed when
> observed data changes. Fluo provides a core API to perform transactional
> updates using minimalistic get/set methods. Fluo also provides a higher
> order recipes API that builds on the core API to support more complex
> methods for transactional updates.
>
> == Background ==
>
> Several frameworks exist for batch (i.e Spark, MapReduce) and stream (i.e
> Storm, Spark Streaming) processing of data. While batch and stream
> processing have strong use cases, they are not suited for joining incoming
> data in real-time to a large existing data set. To fill this need, Google
> developed an incremental processing system called Percolator and described
> it in the paper, ''Large-scale Incremental Processing Using Distributed
> Transactions and Notifications''< http://research.google.com/pubs/pub36726.html)>>.
>
> == Rationale ==
>
> Fluo fills the need for cross-row (and cross-node) transactions in
> Accumulo by providing it with an open source implementation of Percolator.
> Fluo also satisfies a gap in Accumulo’s ability to incrementally process
> data. Fluo also provides a novel recipes API which offers higher level
> abstractions for transactional updates.
>
> == Current Status ==
>
> Fluo currently exists as an open source project on GitHub and has been in
> active development since 2013. The project has made an alpha release and
> two beta releases. The major features of Fluo outlined in this proposal
> have been implemented. Several example Fluo applications have been created
> and run successfully on clusters (up to 24 nodes).
>
> === Meritocracy ===
>
> The Fluo project operates as a meritocracy and will continue to do so
> because we feel that a project comprised of a diverse set of committers
> will thrive. Therefore, we welcome new contributors and encourage them on
> their path to committership.
>
> === Community ===
>
> Fluo is currently being used by a subset of the Accumulo community. The
> initial developers have been responsive to external contributions through
> pull requests and issues on GitHub. As Fluo releases a stable 1.0 version
> that is production-ready, we expect this community to grow. To encourage
> growth, we have created a project website with documentation, given talks
> at Meetups and the Accumulo Summit, and engaged with new users on GitHub
> and the Fluo mailing list.
>
> === Core Developers ===
>
> The project was started by Keith Turner (an Apache Member and
> committer/PMC on Gora and Accumulo) in 2013, and the development has
> primarily consisted of his and Mike Walch’s continued efforts. Additional
> developers have contributed over time, which has led to new committers.
>
> === Alignment ===
>
> Fluo is closely linked to the Accumulo community, and fits well within the
> larger Hadoop ecosystem at Apache. Fluo utilizes several Apache projects,
> such as Accumulo, YARN, Twill, and ZooKeeper. Enabling closer collaboration
> between these communities through its coexistence within the ASF would help
> further drive the success of them all.
>
> In addition to our technical ties to other ASF projects, our development
> philosophy aligns with Apache philosophies. Based on our experience with
> existing Apache projects, we are interested in establishing formal
> governance with a PMC and community bylaws, which we feel would best be
> done within Apache.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> Fluo could be orphaned if the project fails to gain adoption and the core
> developers abandon their interest (this is not anticipated). This risk can
> be mitigated by attracting more committers and developing further
> documentation to ease adoption.
>
> === Inexperience with Open Source ===
>
> Fluo has been an open source project on GitHub from the start of its
> development. Several Fluo developers are committers on other ASF projects
> as well as open source projects outside ASF, and understand open source
> development.
>
> === Homogeneous Developers ===
>
> The initial committers work f

Re: [PROPOSAL] Fluo

[Christopher]

On Tue, May 10, 2016 at 3:52 PM Christopher  wrote:

> On Tue, Apr 19, 2016 at 1:21 PM Christopher  wrote:
>
>> For the incubator consideration, the Fluo developers submit the following
>> proposal:
>> https://wiki.apache.org/incubator/FluoProposal
>>
>> [snip]

>
> Minor update:
>
> We just updated the mentors section of the proposal to include those
> persons with whom we've already spoken about mentoring us, and to exclude
> those with whom we didn't get a chance to personally ask.
>
> The new list includes {drew, billie, elserj}@apache.org
>
>
To clarify, we changed up the mentors listed on the proposal because of a
misunderstanding on our part about who to list. Those persons currently
listed are those we actually discussed mentoring with us, and who expressed
a willingness to do so.

If there's any other persons who'd be interested in offering any mentoring
for Fluo, we'd love to have you as well, if our proposal is accepted into
the incubator.

Re: GitHub vs. the mailing lists

[Christopher]

On Wed, May 18, 2016 at 12:54 PM Jean-Baptiste Onofré 
wrote:

> Hi Mike,
>
> it's what we are doing at Beam.
>
> A PR submission result:
> - to a mail on the mailing list
> - to a comment in Jira (if the PR contains commit with issue ID).
>
>
The GitHub integration is very useful, as it tracks the GitHub PR activity
on the mailing list, and optionally, JIRA (if an issue is referenced).

For the JIRA integration, we recently added a few new options [1]:

(default) - add link to PR on JIRA and comment on the JIRA
"nofollow" - no JIRA integration (mailing only)
"linkonly" - add link to PR on JIRA
"worklog" - add link to PR on JIRA, but use worklog instead of comment

The "worklog" is my preferred option because it reduces mailing list spam
if JIRA is also configured to send email notifications for comments.

[1]: https://issues.apache.org/jira/browse/INFRA-11675

Re: [VOTE] Accept Pony Mail into the Apache Incubator

[Christopher]

+1 (non-binding)

On Tue, May 24, 2016 at 7:41 PM Drew Farris  wrote:

> +1 (binding)
>
> On Tue, May 24, 2016, 5:27 PM Andrew Purtell  wrote:
>
> > +1 (binding)
> >
> >
> > On Mon, May 23, 2016 at 10:56 PM, Daniel Gruno 
> > wrote:
> >
> > > Since it seems the discussion has died down, I am now calling a vote on
> > > accepting Pony Mail into the Incubator. Sorry in advance for potato.
> > >
> > > This vote will run for the usual 72 hours.
> > >
> > > ### PROPOSAL BELOW ###
> > >
> > > Abstract
> > >
> > > Pony Mail is a mail-archiving, archive viewing, and interaction
> service,
> > > that can be integrated with many email platforms.
> > >
> > > Proposal
> > >
> > > Background
> > >
> > > Pony Mail began as a response to two things; the lack of diversity in
> > > mailing list archives that are less bureaucratic all-or-nothing and
> more
> > > fluid way to interact with mailing lists than what is typically
> offered,
> > > and the lack of a performant system that solves this issue. Modern
> users
> > > of software want to jump right into a discussion they see, but cannot
> > > normally do so in a mailing list driven environment because of the
> rules
> > > generally surrounding said environment. Pony Mail, along with a select
> > > handful of newer archive systems, provides an interface that allows
> > > people to just hop into a thread, and take part. Without the need to
> > > subscribe, download the mbox archive, load it into your MTA, and
> respond.
> > >
> > > As Rich writes in a very short essay:
> > >
> > > You see a thread in which someone is WRONG ON THE INTERNET! You need to
> > > correct them. How do you do this today? You kinda don't. If you really
> > > wanted, you could download mbox files (and who the hell knows where
> they
> > > are?) and then try to get them into your mail client (which never
> works)
> > > and then reply to it. Which will break threading, because you did
> > > something wrong. Then you tear out your hair. PONY MAIL TO THE
> RESCUE!!!
> > > (sound of hoof beats)
> > >
> > > Rationale
> > >
> > > One of the oft-heard complaints about Apache's development model is
> that
> > > mailing lists are an old person's tool, and web-based communication -
> > > forums - are the way to go in the 21st Century. Providing a
> > > full-featured forum-like interface to mailing lists is one goal,while
> > > keeping all of the enormous benefits that mailing lists already
> provide.
> > > Asecond goal is to provide the ability to "jump in" to a mailing list
> > > conversation - even one that was a while back, without the convolutions
> > > that a mailing list requires. That is, to join this conversation the
> old
> > > way, one would have had to subscribe to the mailing list, download an
> > > mbox, and import it into ones mail client, in order that I be able to
> > > reply to this message with correct threading. With Pony Mail, one has
> to
> > > do none of those things, but can simply reply using the Web UI. To us,
> > > this is a HUGE benefit for building community. The requirement to jump
> > > through hoops to join a mailing list conversation drives away a lot of
> > > people (at least, anecdotally, it does) and if we can remove that
> > > barrier I think we'll have an easier time of drawing a new generation
> > > into our projects.
> > >
> > > Initial Goals
> > >
> > > The initial goals of transitioning to the ASF is to expand and grow
> both
> > > the Pony codebase and community, and ensure the project's continued
> > > growth and stability through forming a diverse and reliable community,
> > > in which the various facets of developers and contributors help keep
> the
> > > project up to date with latest developments and technical as well as
> > > social needs.
> > >
> > > Current Status
> > >
> > > Meritocracy:
> > >
> > > The bulk of the code has been written by Daniel Gruno to date, but has
> > > had oversight from other committers, and mentors.
> > >
> > > All members of the Pony project and wider community have a deep
> > > understanding and appreciation for the ASF meritocracy ideals, and are
> > > almost solely current ASF Members.
> > >
> > > Community:
> > > The community is currently heavily focused within the ASF, and
> > > more specifically the Infrastructure group. This is to be expected
> given
> > > the nature of how the code came into existence in the first place. It
> > > should be noted that we have started reaching out to other groups who
> we
> > > know are using mailing list systems and therefore also rely on mailing
> > > list archive interfaces.
> > >
> > > Core Developers:
> > >
> > > Almost all core developers are ASF members, and are already intimately
> > > familiar with the Apache Way.
> > >
> > > Alignment:
> > >
> > > Pony will be very in line with ASF practices and processes as many of
> > > the founding members are long term ASF members and committers.
> > >
> > > Known Risks
> > >
> > > Or

[VOTE] Fluo Parent POM 1-incubating (rc2)

[Christopher]

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)

[Christopher]

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

> What is io.fluo and why does this depend on it?  Sounds like a branding
> issue.
>
> On Jul 30, 2016 14:14, "Christopher"  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)

[Christopher]

On Sat, Jul 30, 2016 at 9:55 PM Justin Mclean 
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)

[Christopher]

On Sat, Jul 30, 2016 at 10:07 PM Justin Mclean 
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)

[Christopher]

Thanks Justin. I have a few questions still.

On Sat, Jul 30, 2016 at 10:26 PM Justin Mclean 
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  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)

[Christopher]

On Sat, Jul 30, 2016 at 10:52 PM Justin Mclean 
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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Fluo Parent POM 1-incubating (rc2)

[Christopher]

On Mon, Aug 1, 2016 at 9:37 AM John D. Ament  wrote:

> I'm -1 until the website issues are resolved.
>
> - Make sure its clear that any existing releases are not apache endorsed.
> - Make sure the website points to resources contained within the ASF, e.g.
> fluo-dev is a bit of an oddity same for zetten.
>

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)

[Christopher]

On Sat, Jul 30, 2016 at 11:14 PM Justin Mclean 
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)

[Christopher]

On Mon, Aug 1, 2016 at 3:50 PM John D. Ament  wrote:

> On Mon, Aug 1, 2016 at 10:29 AM Keith Turner  wrote:
>
> > On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament 
> > wrote:
> > > I'm -1 until the website issues are resolved.
> > >
> > > - Make sure its clear that any existing releases are not apache
> endorsed.
> > > - Make sure the website points to resources contained within the ASF,
> > e.g.
> > > fluo-dev is a bit of an oddity same for zetten.
> >
> > Is there a policy on what ASF websites can link to?
> >
>
> Yes.  You have a branding issue.  Fluo is a name owned by the ASF at this
> point.


I'm not sure that's been determined yet. Fluo has not yet completed the
podling name search, and the name "Fluo" did not originate at Apache. It
was in use at "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)

[Christopher]

On Mon, Aug 1, 2016 at 5:23 PM John D. Ament  wrote:

> On Mon, Aug 1, 2016 at 4:21 PM Christopher  wrote:
>
> > On Mon, Aug 1, 2016 at 3:50 PM John D. Ament 
> > wrote:
> >
> > > On Mon, Aug 1, 2016 at 10:29 AM Keith Turner  wrote:
> > >
> > > > On Mon, Aug 1, 2016 at 9:36 AM, John D. Ament  >
> > > > wrote:
> > > > > I'm -1 until the website issues are resolved.
> > > > >
> > > > > - Make sure its clear that any existing releases are not apache
> > > endorsed.
> > > > > - Make sure the website points to resources contained within the
> ASF,
> > > > e.g.
> > > > > fluo-dev is a bit of an oddity same for zetten.
> > > >
> > > > Is there a policy on what ASF websites can link to?
> > > >
> > >
> > > Yes.  You have a branding issue.  Fluo is a name owned by the ASF at
> this
> > > point.
> >
> >
> > I'm not sure that's been determined yet. Fluo has not yet completed the
> > podling name search, and the name "Fluo" did not originate at Apache. It
> > was in use at "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 othe

Re: [VOTE] Fluo Parent POM 1-incubating (rc2)

[Christopher]

On Mon, Aug 1, 2016 at 5:32 PM Craig Russell 
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)

[Christopher]

On Mon, Aug 1, 2016 at 6:22 PM Craig Russell 
wrote:

> Hi Christopher,
>
> > On Aug 1, 2016, at 3:00 PM, Christopher  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.

[CANCEL][VOTE] Fluo Parent POM 1-incubating (rc2)

[Christopher]

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

[Christopher]

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)

[Christopher]

On Mon, Aug 1, 2016 at 8:09 PM John D. Ament  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  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

Re: [VOTE] Fluo Parent POM 1-incubating (rc2)

[Christopher]

On Tue, Aug 2, 2016 at 1:02 AM Alex Harui  wrote:

>
>
> On 8/1/16, 6:52 PM, "Christopher"  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)

[Christopher]

On Wed, Aug 3, 2016 at 9:14 AM Vice President, Brand Management <
vp-br...@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.

SVN dist question

[Christopher]

IPMC,

Can anybody clarify the right location for releases and release candidates
in dist.apache.org while in incubator?

A: For release candidates, would it be:
  A1: https://dist.apache.org/repos/dist/dev/incubator/fluo
or
  A2: https://dist.apache.org/repos/dist/dev/fluo
?

B: For releases, is it:
  B1: https://dist.apache.org/repos/dist/release/incubator/fluo
or
  B2: https://dist.apache.org/repos/dist/release/fluo
?

If the answer for question B is B1, then would releases move to B2 upon
graduation? Or stay in B1 until the first non-incubating release?

I *think* the right answer for A is "doesn't matter", and the right answer
for B is B2, but if that's the case, I'm not sure why /release/incubator
exists.

Thanks for any clarification.

Re: SVN dist question

[Christopher]

On Fri, Aug 5, 2016 at 6:52 PM Julian Hyde  wrote:

> It’s A1 and B1. By the time you graduate, the old releases will have moved
> to archive.apache.org/repos/dist/incubator/fluo <
> http://archive.apache.org/repos/dist/incubator/fluo>, but same problem.
> Incubator releases are not “proper" Apache releases, do not necessarily
> meet the high standard expected of Apache releases, so it’s appropriate
> that they are forever labeled as not-quite-pristine.
>
>
Thanks. That helps.

Just to be clear, I imagine there is often a point of time right after
graduation, where only incubating releases exist. The new TLP should *NOT*
move these from their location in dist/release/incubator (even though they
still have -incubating in their name), but should instead leave them there.
Then, when they release their first non-incubating release, they should put
that in their own dist/release/myNewTLP and remove the incubating releases
so they are only available in the archive. Is that correct?

Re: SVN dist question

[Christopher]

Thank you. Very helpful.

On Fri, Aug 5, 2016, 20:57 Julian Hyde  wrote:

> Yes, that's correct.
>
> All projects (incubating or graduated) remove old releases from
> dist/release. See
> http://www.apache.org/dev/release.html#when-to-archive.
>
> Julian
>
>
> On Fri, Aug 5, 2016 at 3:59 PM, Christopher  wrote:
> > On Fri, Aug 5, 2016 at 6:52 PM Julian Hyde  wrote:
> >
> >> It’s A1 and B1. By the time you graduate, the old releases will have
> moved
> >> to archive.apache.org/repos/dist/incubator/fluo <
> >> http://archive.apache.org/repos/dist/incubator/fluo>, but same problem.
> >> Incubator releases are not “proper" Apache releases, do not necessarily
> >> meet the high standard expected of Apache releases, so it’s appropriate
> >> that they are forever labeled as not-quite-pristine.
> >>
> >>
> > Thanks. That helps.
> >
> > Just to be clear, I imagine there is often a point of time right after
> > graduation, where only incubating releases exist. The new TLP should
> *NOT*
> > move these from their location in dist/release/incubator (even though
> they
> > still have -incubating in their name), but should instead leave them
> there.
> > Then, when they release their first non-incubating release, they should
> put
> > that in their own dist/release/myNewTLP and remove the incubating
> releases
> > so they are only available in the archive. Is that correct?
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] move the Incubator Report section to SVN or GIT?

[Christopher]

On Mon, Aug 8, 2016 at 3:34 AM Mark Struberg 
wrote:

> Another possible option would be to move it to our CMS.
>
> That would bring us SVN for the people who prefer vi, but also a graphical
> UI for editing.
> And it would make people make familiar with our CMS.


I prefer the Wiki over CMS. I find CMS to be clumsy and annoying. I'm glad
the projects I'm involved in no longer use (or never have used) it. I'd be
willing to use SVN (reluctantly, and with git-svn), but if it were tied to
CMS, there'd still be the second publication step using CMS which would be
annoying.

There is something to be said about the low barrier to entry of a Wiki,
though. Anybody can do it. It's the least developer-centric way of doing
things out there. I know CMS tries to be that, but it hasn't quite
succeeded.

[VOTE] Apache Fluo parent POM 1 and Build Resources 1.0.0

[Christopher]

IPMC,

Please consider the following candidates for Fluo Parent POM 1-incubating
and Fluo Build Resources 1.0.0-incubating. There are two artifacts, which
we are releasing together. They do not contain Fluo itself, but are
prerequisites for the Maven build of Fluo, which will be released via Maven
upon successful passing of this vote. Releasing these to Maven will bring
us a step closer to preparing release candidates for Fluo itself.

Passing PPMC release vote thread:

https://lists.apache.org/thread.html/7f9a1db3798ddc4123ba3c66c632cedde6272ba55f1132d556f24a67@%3Cdev.fluo.apache.org%3E

Since the last attempted vote, we have taken significant steps to ensure
that Apache retains exclusive use of the Fluo trademark. Historical
releases still exist in Maven Central under the "io.fluo" groupId, but the
original fluo.io site has been redirected to fluo.apache.org (until its
domain registration expires, at which point our plan is to let it lapse),
and references to pre-Apache releases have been marked explicitly as such
on the Fluo website. The organization containing related 3rd party software
for Fluo was renamed in GitHub from fluo-io to astralway, so as not to
misappropriate the Fluo trademark, and references to Fluo on those external
projects have made it a point to explicitly refer to "Apache Fluo". The
fluo.apache.org website will continue to be updated as we start making
Apache releases, but we don't anticipate any future trademark concerns such
as those noted in the previously canceled vote thread. Please let us know
if we've overlooked something.

Release artifacts are staged at:
  https://dist.apache.org/repos/dist/dev/incubator/fluo/
and in a Nexus Staging repo:
  https://repository.apache.org/content/repositories/orgapachefluo-1004
for convenience.

Signing key fingerprint is:
  8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
KEYS in:
  https://www.apache.org/dist/incubator/fluo/KEYS

Git Commits (branches) in
https://git-wip-us.apache.org/repos/asf/incubator-fluo.git:
02d4ea2332598a94285985ee8a1c8e92a42b4770 (build-resources-1.0.0-rc1)
95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)

If this vote passes, gpg-signed tags will be created using:
git tag -f -m 'Apache Fluo Build Resources 1.0.0-incubating' -s
rel/build-resources-1.0.0-incubating
02d4ea2332598a94285985ee8a1c8e92a42b4770
git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
rel/fluo-parent-1-incubating 95c48e3f14faf5cdca259d8ec60ec68b640fce1e

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
and 1.0.0-incubating release of Apache Fluo Build Resources.

This vote will end on Thu Aug 11 21:30:00 UTC 2016
(Thu Aug 11 17:30:00 EDT 2016 / Thu Aug 11 14:30:00 PDT 2016)

Thanks!

Re: [VOTE] Apache Fluo parent POM 1 and Build Resources 1.0.0

[Christopher]

On Mon, Aug 8, 2016 at 6:29 PM John D. Ament  wrote:

> +1 release contents look good.  Thank you for your due diligence on this
> release.
>
> I'll reply separately about the other comments, to not throw off this
> thread.
>
> Nitpick: Check your signature, may not be valid:
>
> gpg: WARNING: This key is not certified with a trusted signature!
>
> gpg:  There is no indication that the signature belongs to the
> owner.
>

That warning from gpg is not controllable by me. It's a warning about your
own local trust database. The warning indicates that you have not yet made
a determination of whether you trust my key or not. It usually follows the
message about the signature being valid (
https://www.gnupg.org/gph/en/manual/x334.html).

A fair number of folks have signed my key during previous ApacheCon
keysigning parties, so you may be able to trust my key transitively if you
trust one of theirs. Or, I think you can just set the trust level either
manually, or by signing it with your own key (maybe at the next ApacheCon
I'm able to attend).

Re: [DISCUSS] Apache Fluo Branding

[Christopher]

On Mon, Aug 8, 2016 at 9:00 PM John D. Ament  wrote:

> Christopher,
>
> I wanted to start a separate thread regarding some of your branding
> comments below, to make sure we're all on the same page.
>
> On Mon, Aug 8, 2016 at 5:24 PM Christopher  wrote:
>
> > IPMC,
> >
> > Please consider the following candidates for Fluo Parent POM 1-incubating
> > and Fluo Build Resources 1.0.0-incubating. There are two artifacts, which
> > we are releasing together. They do not contain Fluo itself, but are
> > prerequisites for the Maven build of Fluo, which will be released via
> Maven
> > upon successful passing of this vote. Releasing these to Maven will bring
> > us a step closer to preparing release candidates for Fluo itself.
> >
> > Passing PPMC release vote thread:
> >
> >
> >
> https://lists.apache.org/thread.html/7f9a1db3798ddc4123ba3c66c632cedde6272ba55f1132d556f24a67@%3Cdev.fluo.apache.org%3E
> >
> > Since the last attempted vote, we have taken significant steps to ensure
> > that Apache retains exclusive use of the Fluo trademark. Historical
> > releases still exist in Maven Central under the "io.fluo" groupId, but
> the
> > original fluo.io site has been redirected to fluo.apache.org (until its
> > domain registration expires, at which point our plan is to let it lapse),
> >
>
> This is all expected.  We don't replace those releases, just need to make
> sure they're pre-apache releases and regarded as such.  Its really just a
> call out to make sure its clear they're not vetted the way releases will be
> vetted.
>
>
We're on the same page here. I mentioned it because it was raised as a
concern in the previous (canceled) vote thread, and I wanted to report back
on our progress. :)


> Regarding the domain name, an option there for you is to donate fluo.io to
> the ASF as a part of joining the incubator.  You may want to follow up with
> infra directly, but typically they do maintain domain names for projects,
> as long as its all hosted on our infrastructure.
>
>
We (the current owners of fluo.io) discussed this off list. We'd be willing
to donate it to ASF, but we don't feel we really need the domain, so
there's not really a motivation on our end to burden the ASF with the cost
of maintaining it. If the Foundation has an interest in managing the
domain, we'd gladly transfer it, but it's not something we think will
benefit the project. So, we thought it best to just let it lapse.

Re: [VOTE] Apache Fluo parent POM 1 and Build Resources 1.0.0

[Christopher]

On Mon, Aug 8, 2016 at 8:47 PM Justin Mclean 
wrote:

> Hi,
>
> +1 binding
>
> I checked:
> - incubating in release name
> - DISCLAIMER exists
> - LICENSE and NOTICE fine
> - No binaries in the release
> - can compile from source
>
> Only one small niggle is that "build-resources-1.0.0-incubating” (one of
> the two artefacts in the release) seems an unusual name for an apache
> release as neither the project name or apache is mentioned in it’s name.
>
>
If it helps, I discussed the naming of these files in IRC with one of our
mentors, and copied the transcript to our dev@ list (
https://lists.apache.org/thread.html/e05a699ca15d629f2f82f6eec78ac0335116171ba32481720baad470@%3Cdev.fluo.apache.org%3E
)

The summary is that these are primarily intended for deployment to a Maven
repository (in particular, Maven Central via repository.apache.org), for
building Fluo projects, and they are marked with the "org.apache.fluo"
groupId. We felt that adding to the artifactId in Maven would introduce
redundancy and confusion.

Re: [VOTE] Apache Fluo parent POM 1 and Build Resources 1.0.0

[Christopher]

Just a quick reminder about this vote, which expires tomorrow. So far,
there are +3

On Tue, Aug 9, 2016 at 1:38 PM Josh Elser  wrote:

> Forwarding my (binding) +1 from the PPMC vote.
>
> Christopher wrote:
> > IPMC,
> >
> > Please consider the following candidates for Fluo Parent POM 1-incubating
> > and Fluo Build Resources 1.0.0-incubating. There are two artifacts, which
> > we are releasing together. They do not contain Fluo itself, but are
> > prerequisites for the Maven build of Fluo, which will be released via
> Maven
> > upon successful passing of this vote. Releasing these to Maven will bring
> > us a step closer to preparing release candidates for Fluo itself.
> >
> > Passing PPMC release vote thread:
> >
> >
> https://lists.apache.org/thread.html/7f9a1db3798ddc4123ba3c66c632cedde6272ba55f1132d556f24a67@%3Cdev.fluo.apache.org%3E
> >
> > Since the last attempted vote, we have taken significant steps to ensure
> > that Apache retains exclusive use of the Fluo trademark. Historical
> > releases still exist in Maven Central under the "io.fluo" groupId, but
> the
> > original fluo.io site has been redirected to fluo.apache.org (until its
> > domain registration expires, at which point our plan is to let it lapse),
> > and references to pre-Apache releases have been marked explicitly as such
> > on the Fluo website. The organization containing related 3rd party
> software
> > for Fluo was renamed in GitHub from fluo-io to astralway, so as not to
> > misappropriate the Fluo trademark, and references to Fluo on those
> external
> > projects have made it a point to explicitly refer to "Apache Fluo". The
> > fluo.apache.org website will continue to be updated as we start making
> > Apache releases, but we don't anticipate any future trademark concerns
> such
> > as those noted in the previously canceled vote thread. Please let us know
> > if we've overlooked something.
> >
> > Release artifacts are staged at:
> >https://dist.apache.org/repos/dist/dev/incubator/fluo/
> > and in a Nexus Staging repo:
> >https://repository.apache.org/content/repositories/orgapachefluo-1004
> > for convenience.
> >
> > Signing key fingerprint is:
> >8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
> > KEYS in:
> >https://www.apache.org/dist/incubator/fluo/KEYS
> >
> > Git Commits (branches) in
> > https://git-wip-us.apache.org/repos/asf/incubator-fluo.git:
> >  02d4ea2332598a94285985ee8a1c8e92a42b4770 (build-resources-1.0.0-rc1)
> >  95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
> >
> > If this vote passes, gpg-signed tags will be created using:
> >  git tag -f -m 'Apache Fluo Build Resources 1.0.0-incubating' -s
> > rel/build-resources-1.0.0-incubating
> > 02d4ea2332598a94285985ee8a1c8e92a42b4770
> >  git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
> > rel/fluo-parent-1-incubating 95c48e3f14faf5cdca259d8ec60ec68b640fce1e
> >
> > 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
> > and 1.0.0-incubating release of Apache Fluo Build Resources.
> >
> > This vote will end on Thu Aug 11 21:30:00 UTC 2016
> > (Thu Aug 11 17:30:00 EDT 2016 / Thu Aug 11 14:30:00 PDT 2016)
> >
> > Thanks!
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[RESULT][VOTE] Apache Fluo parent POM 1 and Build Resources 1.0.0

[Christopher]

This vote passes with +3 (johndament, jmclean, elserj), and no -1.
Thanks all!

On Wed, Aug 10, 2016 at 4:27 PM Christopher  wrote:

> Just a quick reminder about this vote, which expires tomorrow. So far,
> there are +3
>
>
> On Tue, Aug 9, 2016 at 1:38 PM Josh Elser  wrote:
>
>> Forwarding my (binding) +1 from the PPMC vote.
>>
>> Christopher wrote:
>> > IPMC,
>> >
>> > Please consider the following candidates for Fluo Parent POM
>> 1-incubating
>> > and Fluo Build Resources 1.0.0-incubating. There are two artifacts,
>> which
>> > we are releasing together. They do not contain Fluo itself, but are
>> > prerequisites for the Maven build of Fluo, which will be released via
>> Maven
>> > upon successful passing of this vote. Releasing these to Maven will
>> bring
>> > us a step closer to preparing release candidates for Fluo itself.
>> >
>> > Passing PPMC release vote thread:
>> >
>> >
>> https://lists.apache.org/thread.html/7f9a1db3798ddc4123ba3c66c632cedde6272ba55f1132d556f24a67@%3Cdev.fluo.apache.org%3E
>> >
>> > Since the last attempted vote, we have taken significant steps to ensure
>> > that Apache retains exclusive use of the Fluo trademark. Historical
>> > releases still exist in Maven Central under the "io.fluo" groupId, but
>> the
>> > original fluo.io site has been redirected to fluo.apache.org (until its
>> > domain registration expires, at which point our plan is to let it
>> lapse),
>> > and references to pre-Apache releases have been marked explicitly as
>> such
>> > on the Fluo website. The organization containing related 3rd party
>> software
>> > for Fluo was renamed in GitHub from fluo-io to astralway, so as not to
>> > misappropriate the Fluo trademark, and references to Fluo on those
>> external
>> > projects have made it a point to explicitly refer to "Apache Fluo". The
>> > fluo.apache.org website will continue to be updated as we start making
>> > Apache releases, but we don't anticipate any future trademark concerns
>> such
>> > as those noted in the previously canceled vote thread. Please let us
>> know
>> > if we've overlooked something.
>> >
>> > Release artifacts are staged at:
>> >https://dist.apache.org/repos/dist/dev/incubator/fluo/
>> > and in a Nexus Staging repo:
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1004
>> > for convenience.
>> >
>> > Signing key fingerprint is:
>> >8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
>> > KEYS in:
>> >https://www.apache.org/dist/incubator/fluo/KEYS
>> >
>> > Git Commits (branches) in
>> > https://git-wip-us.apache.org/repos/asf/incubator-fluo.git:
>> >  02d4ea2332598a94285985ee8a1c8e92a42b4770
>> (build-resources-1.0.0-rc1)
>> >  95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
>> >
>> > If this vote passes, gpg-signed tags will be created using:
>> >  git tag -f -m 'Apache Fluo Build Resources 1.0.0-incubating' -s
>> > rel/build-resources-1.0.0-incubating
>> > 02d4ea2332598a94285985ee8a1c8e92a42b4770
>> >  git tag -f -m 'Apache Fluo Parent POM 1-incubating' -s
>> > rel/fluo-parent-1-incubating 95c48e3f14faf5cdca259d8ec60ec68b640fce1e
>> >
>> > 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
>> > and 1.0.0-incubating release of Apache Fluo Build Resources.
>> >
>> > This vote will end on Thu Aug 11 21:30:00 UTC 2016
>> > (Thu Aug 11 17:30:00 EDT 2016 / Thu Aug 11 14:30:00 PDT 2016)
>> >
>> > Thanks!
>> >
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: Ease of release process and exit criteria

[Christopher]

On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg 
wrote:

> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate
> ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The important parts are
> false
> true
>
>
+1 This is super-critical for maven-release-plugin users. It'd be nice to
have these in the parent POM, but there is also a risk that the source code
which is actually used to create the release candidate is never pushed to
the repository. There's actually quite a few manual steps outside the
maven-release-plugin one must do in ASF to get things staged, uploaded, and
ready for a vote.

To solve this for Accumulo, I wrote a pretty comprehensive build script
that automates some of the manual steps we'd normally do with git during
and after the maven commands to stage the release candidate in Nexus:
https://s.apache.org/accumulo-build-script

Unfortunately, we've not done a good job of ensuring the documentation is
up-to-date to document this process manually. It's on my TODO list, though,
and I think it'd be great for incubating projects to ensure the steps
(whatever they are for their particular project) to create release
candidates is documented prior to graduation.

Re: Ease of release process and exit criteria

[Christopher]

By "source package must be able to build itself", are you suggesting that
simple projects must create scripts inside the source itself to execute a
simple tar/zip command (for example), instead of just documenting those
lines? That seems a bit frivolous to me.

On Sun, Aug 21, 2016 at 1:59 AM Alex Harui  wrote:

> One more thought on this:  Right now the 'requirement' is for PMC members
> to be able to take the source package and build the binary before voting
> +1.  What if the 'requirement' became that the PMC members must be able to
> take the source package and build both the binary and the source package?
> IOW, a source package must be able to build itself.
>
> Thanks,
> -Alex
>
> On 8/20/16, 12:59 PM, "Mark Thomas"  wrote:
>
> >All,
> >
> >It seems there is general consensus that this is a good idea. I'm
> >therefore going to do the following.
> >
> >1. Draft some text to add to
> >   http://incubator.apache.org/guides/graduation.html#releases
> >   and bring that back to this list for discussion
> >
> >2. Start a thread on dev@community about adding an item to the project
> >   maturity model.
> >
> >3. Identify somewhere to put all the good suggestions for, and links to
> >   examples of, smooth release processes and then pull all the links
> >   and suggestions from this thread to that place. I have a vague
> >   recollection of seeing such a thing previously. I'll need to do some
> >   digging to see it I can find it. Any hints?
> >
> >Mark
> >
> >
> >On 19/08/2016 21:41, Dave Fisher wrote:
> >> I know of a podling like that where the release manager gave me push
> >>back until I told him I could not vote +1 without build instructions I
> >>could at least follow on my own local.
> >>
> >> That was some years ago. The podling graduated. The instructions were
> >>not updated. The RM left. Now there is a bind.
> >>
> >> A requirement is a good idea, but it is no guarantee that the
> >>instructions remain up to date.
> >>
> >> Suggestions:
> >>
> >> Is this info for the maturity model?
> >> Should there be special and higher standards to make binary releases
> >>"official"?
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton
> >>> wrote:
> >>>
> >>> +1 to this, including the posts from Mark and Bertrand.
> >>>
> >>> I know of a project where this would have made a serious difference
> >>>for graduation and subsequent sustainability.
> >>>
> >>> - Dennis
> >>>
>  -Original Message-
>  From: Shane Curcuru [mailto:a...@shanecurcuru.org]
>  Sent: Friday, August 19, 2016 07:08
>  To: general@incubator.apache.org
>  Subject: Re: Ease of release process and exit criteria
> 
>  Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> > Hi Mark,
> >
> > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 
>  wrote:
> >> ...I'm thinking of a graduation criteria long the lines of:
> >> "Is the release process clearly documented to the point that someone
>  new
> >> to the project could produce a release build?"...
> 
>  +1, this is a critical point to include.  We continue to see projects
>  struggling with releases when early volunteers leave and no-one else
>  really understands releases.
> 
>  ...snip...
> > How about also adding an RE50 item to
> > https://community.apache.org/apache-way/apache-project-maturity-
>  model.html
> > about a repeatable release process? That's a discussion for
> > community.a.o but what's your opinion?
> 
>  +1, this is both important to include philosophically as well as
>  practically.  I.e. it's an important reminder that project technical
>  procedures need to be understandable by the *whole* community, not
> just
>  the first few developers who created the project.
> 
>  - Shane
> 
>  -
>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>

Re: Licensing requirement for binary artifacts without transitive deps

[Christopher]

As I understand things, the licensing information you provide in your
artifacts should reflect everything contained within that artifact. You do
not need to provide license/notice information for dependencies which are
not bundled in your artifact.

On Tue, Sep 20, 2016 at 3:01 PM Donald Szeto  wrote:

> Sorry. I should have mentioned that I am preparing a release for
> PredictionIO.
>
> Regards,
> Donald
>
> On Tuesday, September 20, 2016, Donald Szeto  wrote:
>
> > Hi all,
> >
> > I am preparing my first Apache release and am wondering if I need to
> check
> > licenses of all transitive deps if the release contains:
> >
> > - a single source tarball;
> > - a few binary JAR artifacts on Nexus that contain no transitive deps in
> > either binary or source form.
> >
> > Would it be sufficient to make sure the licenses of all sources comply
> > with Apache policy in this case? Do I need to check transitive deps in
> this
> > case?
> >
> > Thanks!
> >
> > Regards,
> > Donald
> >
>

[VOTE] Apache Fluo 1.0.0-incubating (rc2)

[Christopher]

Dear IPMC,

Please vote for the following release candidate of Apache Fluo
1.0.0-incubating.

PPMC vote thread:
https://lists.apache.org/thread.html/8b6ec5f17e277ed2d01e8df61eb1f1f42266cd30b9e114cb431c1c17@%3Cdev.fluo.apache.org%3E

Staged dist artifacts:
https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.0.0-incubating-rc2/

Staged Maven repository:
https://repository.apache.org/content/repositories/orgapachefluo-1013/

Signing KEYS:
https://www.apache.org/dist/incubator/fluo/KEYS
(fingerprint for this release: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)

Git repo:
https://git-wip-us.apache.org/repos/asf/incubator-fluo
(branch: 1.0.0-incubating-rc2,
commit: e1dbc608c67f31e804b59abd69d0bc530ca00f77)

This vote will end on Tue Oct  4 03:00:00 UTC 2016
(Mon Oct  3 23:00:00 EDT 2016 / Mon Oct  3 20:00:00 PDT 2016)

Re: [VOTE] Apache Fluo 1.0.0-incubating (rc2)

[Christopher]

Bump. Just want to remind IPMC this vote ends tonight at 11pm Eastern.

On Fri, Sep 30, 2016 at 10:55 PM Christopher  wrote:

> Dear IPMC,
>
> Please vote for the following release candidate of Apache Fluo
> 1.0.0-incubating.
>
> PPMC vote thread:
>
> https://lists.apache.org/thread.html/8b6ec5f17e277ed2d01e8df61eb1f1f42266cd30b9e114cb431c1c17@%3Cdev.fluo.apache.org%3E
>
> Staged dist artifacts:
>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.0.0-incubating-rc2/
>
> Staged Maven repository:
> https://repository.apache.org/content/repositories/orgapachefluo-1013/
>
> Signing KEYS:
> https://www.apache.org/dist/incubator/fluo/KEYS
> (fingerprint for this release: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>
> Git repo:
> https://git-wip-us.apache.org/repos/asf/incubator-fluo
> (branch: 1.0.0-incubating-rc2,
> commit: e1dbc608c67f31e804b59abd69d0bc530ca00f77)
>
> This vote will end on Tue Oct  4 03:00:00 UTC 2016
> (Mon Oct  3 23:00:00 EDT 2016 / Mon Oct  3 20:00:00 PDT 2016)
>
>

[RESULT][VOTE] Apache Fluo 1.0.0-incubating (rc2)

[Christopher]

Calling the vote: +3, and no other votes.

(Note, since I'm calling the vote late, I've included Billie's vote, which
was received after the initial 72 hours, but since there were no -1 or
+/-0 votes and I didn't get a chance to call it before she voted, this
seems reasonable. IPMC, please let us know if not.)

Points raised in the vote:

1) We'll take steps to add license headers to the generated code in the
build, immediately following generation, so that users will be properly
informed about their re-distribution rights for these files. That change
will appear in the next release.

2) It has been suggested to add "apache-" prefix to artifacts. We've
thought about, and discussed this previously. I understand the reasons, but
as it's not a requirement, I think we'd prefer to not do it. I'm confident
we can protect the Apache Fluo brand, and promote Apache, without changing
the file name.

The problem is, these artifacts are generated during the automatic build
process using Maven, and in order to add that prefix, it would be required
to modify the Maven artifactId to redundantly add "apache" to the Maven
coordinates (it already appears in the groupId), and possibly make other
changes to the default build tooling. It also complicates things for
downstream packaging, and is a bit unnatural for a Maven project. Since
there is precedent for not doing this (including httpd, hadoop, commons,
and all of the maven plugins), it doesn't seem to be required, and there
are good reasons not to do it, I'm inclined to keep things as they are, but
appreciate the suggestion being made. As I said, I'm confident we can
protect the brand without that step.

On Tue, Oct 4, 2016 at 10:51 AM Billie Rinaldi  wrote:

> +1 binding
> - signatures and checksums are good
> - builds from source and tests pass except GarbageCollectionIteratorIT
> - source tarball matches tag
> - L&N and headers look good
> - DISCLAIMER is good and file names contain incubating
>
> On Fri, Sep 30, 2016 at 10:55 PM Christopher  wrote:
> > Dear IPMC,
> >
> > Please vote for the following release candidate of Apache Fluo
> > 1.0.0-incubating.
> >
> > PPMC vote thread:
> >
> > https://lists.apache.org/thread.html/8b6ec5f17e277ed2d01e8df61eb1f1
> f42266cd30b9e114cb431c1c17@%3Cdev.fluo.apache.org%3E
> >
> > Staged dist artifacts:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/
> 1.0.0-incubating-rc2/
> >
> > Staged Maven repository:
> > https://repository.apache.org/content/repositories/orgapachefluo-1013/
> >
> > Signing KEYS:
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (fingerprint for this release: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > Git repo:
> > https://git-wip-us.apache.org/repos/asf/incubator-fluo
> > (branch: 1.0.0-incubating-rc2,
> > commit: e1dbc608c67f31e804b59abd69d0bc530ca00f77)
> >
> > This vote will end on Tue Oct  4 03:00:00 UTC 2016
> > (Mon Oct  3 23:00:00 EDT 2016 / Mon Oct  3 20:00:00 PDT 2016)
> >
> >
>

Re: [EXAMPLE] bootstrapping (was: Apache Example project?)

[Christopher]

On Tue, Oct 4, 2016 at 6:25 PM Josh Elser  wrote:

>
>
> Stian Soiland-Reyes wrote:
> > On 3 October 2016 at 06:30, Luciano Resende
> wrote:
> >> +1,
> >>
> >> I had started something similar, at least on the website side, with best
> >> practices and required branding items.
> >>
> >> Please consider adding it to the "example" project :
> >>
> >> https://github.com/apache/apache-website-template
> >
> > Brilliant - yes, that's exactly the kind of thing I mean!  You've
> > already got a great Community page there:
> >
> https://github.com/apache/apache-website-template/blob/master/site/community.md
> >
> >
> > So - how do we proceed? I suggest to use the [EXAMPLE] tag on this
> > list as there could be a couple of things we need to agree (not
> > discuss!) what best practice actually is.
> >
> > Do we need an IPMC vote?
> >
> > We need to request from infra something like:
> >
> > git repository incubator-example
> >- w/ pull request sync to general@incubator ?
> >
> > Jira  (or brave: GH issues? Fluo can inform us)
>
> As far as I know, after we got everything set up (which, admittedly, I
> think was more tricky because pre-ASF "fluo" was already on Github, code
> and issues), GH issues have been smooth-sailing. As long as you're OK
> with closing issues via git commit message, anyways :)
>
>
Closing issues with FF merge or git commit message isn't a big deal, but
the biggest issue with using GH issues at ASF is the lack of ability to use
labels/milestones for issue-tracking/planning. Some of that can be done
manually with Wiki/mailing list, but it's kind of a pain. There can also be
a lot of duplicate spam to users if they subscribe to GH issues, and then
also subscribe to the mailing lists for activity notifications.


> > git repository incubator-example-site
> >(alternatives: apache/apache-website-template as-is; site/ folder in
> > incubator-example repo)
> >
> > http://example.incubator.apache.org/
> >- and corresponding git2pub
> >
> >
> > I am not sure about separate mailing list (who would sign up?)
> > although we can fake that on its mailing list page.
> >
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Article on community building

[Christopher]

Forwarding this post from the Fluo dev list, to get wider Incubator
feedback.

Keith's comment shows the importance of labels in the issue tracker (which
is a known limitation in ASF's use of GitHub issues) to try to reach out to
new contributors.

Does anybody have any other suggestions for trying to reach out and grow a
podling's community?

-- Forwarded message -
From: Keith Turner
Date: Tue, Oct 25, 2016 at 6:40 PM
Subject: Article on community building
To: 


I found the following article on community building interesting. Its
annoying that we can not label issues for first time contributors in GH.
It would be nice to be able to label issues and then post a link to a GH
issue search to some of the places mentioned in the article.

http://hood.ie/blog/welcoming-communities.html

Re: [VOTE] Apache Beam release 0.3.0-incubating

[Christopher]

I believe the DEPENDENCIES file is produced by the Apache Parent POM's
execution of the maven-remote-resources-plugin, and it is generated when
the 'apache-release' profile is active during a release.

On Sat, Oct 29, 2016 at 2:07 AM Dan Halperin 
wrote:

> Hi Justin,
>
> Thanks for excellent detailed analysis, as usual!
>
> 1) Hmm! I do see a file called `DEPENDENCIES` in the source release [0],
> but it is not checked in [1]. It must be introduced somehow by `mvn
> release-plugin`, following our release process [2].
>To clear up some possible confusion: We **definitely** run Apache RAT in
> the release profile [3], which is ran continually on every single commit
> [4], and this has indeed caught unlicensed files. [5] Because DEPENDENCIES
> is not under version control but somehow ended up in the source release,
> RAT does not help here.
>We'll have to find where in the release process this file was
> introduced. This same issue happened in the two prior incubating releases,
> but was not noticed :/.
>Hmm!
>
> [0]
> https://dist.apache.org/repos/dist/dev/incubator/beam/0.3.0-incubating/
> [1]
>
> https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/DEPENDENCIES
> (HTTP 404 expected)
> [2] http://beam.incubator.apache.org/contribute/release-guide/
> [3]
>
> https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/pom.xml#L197
> [4] Example:
>
> https://builds.apache.org/job/beam_PreCommit_MavenVerify/4362/org.apache.beam$beam-parent/console
>
> [5]
>
> https://github.com/apache/incubator-beam/pull/1199/commits/0addd4c7138211cdfb9056101c8e13325ad3de58
>
> 2) I'm not sure precisely what the definition of `optional` is; I'd like
> some clarification. We do indeed build the module by default, but it is not
> in any way required to use Beam. For example:
>Beam's examples [6] module does not depend on Kinesis. This is a key
> user starting point -- the examples provide many useful, flagship
> end-to-end Beam pipelines. The same goes for our Maven archetypes for the
> examples [7] and starter projects [8]. In fact, no module depends on the
> module that provides Kinesis, explicitly so that it is completely unused
> unless a user opts into it.
>
> [6]
>
> https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/examples/pom.xml
> [7]
>
> https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/sdks/java/maven-archetypes/examples/src/main/resources/archetype-resources/pom.xml
> [8]
>
> https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/sdks/java/maven-archetypes/starter/src/main/resources/archetype-resources/pom.xml
>
> Thanks,
> Dan
>
> On Fri, Oct 28, 2016 at 10:37 PM, Justin Mclean 
> wrote:
>
> > Hi,
> >
> > > We discussed about this dependency on the dev mailing list.
> >
> > Yep I read that discussion and it seems to me to be missing the main
> > point. Yes you can’t have Category X software in a release but you can’t
> > have it as a dependancy either unless it’s optional.
> >
> > > The dependency is not embedded in any Beam distribution or jar file.
> The
> > users have to explicitly define the dependency to be able to use the
> > Kinesis IO.
> >
> > Which may not be enough IMO. The question to ask is “Will most users want
> > to use Kinesis IO or not?"
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Policy Question: GA for GitHub for Podlings

[Christopher]

Sorry if these questions have already been answered, but I'm still a bit
confused, so if anybody can answer I'd be grateful.

Why is GA for podlings being considered before GA for TLPs? Or, is GitHub
already generally available to TLPs, and I missed that? If I didn't miss
anything, what are the arguments in favor of and against enabling this for
podlings first?

How does this relate to M.A.T.T.? Is that still being piloted, or is that
now generally available to projects? Is this something different?

Are we talking about granting PMCs admin on the repos, and committers
write-access? Or, only PMC chair admin, or some other combination of access
grants?

Will this enable projects to manage GitHub issue labels and milestones?
That's been really sorely lacking in the Fluo podling since we transitioned
to incubation from our previous GitHub home, and it'd be *really* nice to
get that working again.

On Tue, Nov 8, 2016 at 6:47 PM Niall Pemberton 
wrote:

> I'm +1 to this for OpenWhisk.
> I'm -1 to this as a general availability.
>
> There could be issues down the road which means that this option is
> withdrawn. I'd hate to have alot of podlings with an expectation that were
> later disappointed.
>
> Niall
>
> On Mon, Nov 7, 2016 at 9:50 PM, Chris Mattmann 
> wrote:
>
> > Hi,
> >
> > As some of you may have seen the OpenWhisk podling being discussed now
> has
> > requested to use GitHub as its primary master. Greg Stein our ASF Infra
> > Admin
> > has OK’ed this for OpenWhisk iff the IPMC is OK with it.
> >
> > I ask now:
> >
> > 1. Is the IPMC OK with this for OpenWhisk?
> > 2. Is the IPMC OK with this in general availability for Podlings?
> >
> > I am +1 on both (IPMC hat on).
> >
> > Thanks.
> >
> > Cheers,
> > Chris
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Omitting "-incubating" suffix in Maven artifact version attribute for FreeMarker

[Christopher]

I think it could also be confusing for users of the Maven version didn't
match the IPMC released version identifier.

If anything, it probably makes more sense to have the '-incubating' in the
groupId , since it's the endorsement of the foundation which is in the
interim state. The groupId typically contains the TLP name, which would be
incubator. So, org.apache.incubator? I would like that along with dropping
the incubating suffix on all artifact versions (Maven or not).

I think it's generally confusing for users to have the suffix present, and
redundant when the artifact readme, pom metadata, or other files explain
it's status more clearly. It also creates excessively long file names and
the naming convention conflicts with other post-version identifiers, such
as Maven classifiers and RPM release/arch info.

On Tue, Dec 27, 2016, 20:18 Daniel Dekany  wrote:

> Hello,
>
> The last release of Apache FreeMarker (incubating) has these Maven
> coordinates:
>
> org.freemarker
> freemarker
> 2.3.25-incubating
>
> The "-incubating" in the Maven version is confusing for the users, as
> it looks as the version number of an unstable release, and it seems
> that this causes many to stick to the last non-Apache release from 1.5
> years ago. (See the "*" footnote if you want some more details.)
>
> As far as I know there's no explicit requirement for having
> "incubating" in the Maven artifact version number. So, I wonder, can
> we just omit "-incubating" from the Maven artifact versions from now
> on? In FreeMarker's case the Maven groupId doesn't contain org.apache
> (I know, it should, but that's a different topic), so I guess there's
> less danger of branding confusion here. Of course, the version number
> would remain x.x.x-incubating in the file names of the releases
> downloadable from apache.org and so on. Also, in case it bothers
> anyone, the "name" element in the Maven POM could be changed from
> "Apache FreeMarker" to "Apache FreeMarker (incubating)" (or just to
> "FreeMarker").
>
> *: For those not working in the Java ecosystem, know that many users
>will not go to the project home page nowadays to find the latest
>version, just look at the versions at the Maven Central. Without
>any place for explanation, "2.3.25-incubating" and such are often
>believed to be development versions. (I have seen a few user
>queries that indicated that too.) It certainly doesn't help either
>that http://mvnrepository.com automatically marks these incubating
>versions with red (~ alpha). Also, on the same place the last
>non-Apache release has almost 5x more usages than the last two
>"-incubating" releases together, which is suspicious. Spring has
>also stuck at that version for some reason.
>
> --
> Thanks,
>  Daniel Dekany
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Omitting "-incubating" suffix in Maven artifact version attribute for FreeMarker

[Christopher]

On Tue, Dec 27, 2016 at 9:43 PM John D. Ament  wrote:

> I personally have received negative feedback from both colleagues and
> management on the use of projects with the name "incubating" in them,
> putting them into the same category as alpha or beta software.
>
> When Daniel brought this up on the freemarker list, I did give him my
> support in the matter.  I've sent a few emails recently about updating
> incubator policies and guides, to fix problems that have been identified.
> As far as I'm concerned, what he's asking doesn't require any change - the
> use of -incubating in the version # has been a self imposed rule, not a
> policy the incubator has requested [1] (note the should).
>
> As far as including it in the group ID, I would expect it to then look like
> "org.apache.incubator.podling" but then we are mandating maven coordinates,
>

Yes, that's what I was thinking.


> which thus far the ASF has not done [2].  I actually prefer the
> non-mandated approach, since as you mention, all of the supporting
> materials require the disclaimer.
>
>
I agree that mandating coords isn't the right way to go, but it might be
okay to suggest coords. In any case, I'm not as much of a fan of this as I
was when I first thought of it earlier... it creates an unnecessary
transition pre-/post-graduation. And, it doesn't help with anything if the
IPMC continues to require the suffix in the release tarball and the release
tarball is built using maven-assembly-plugin (a sensible thing to do).


> The actual requirement, as I've understood it, is that the release artifact
> (the source tarball) includes -incubating.  Not generated maven artifacts
> (which are the output of that source tarball).
>
>
The one complication here is that the release artifact (source tarball) is
most easily created with a maven project by using the maven-assembly-plugin
with the source tarball assembly defined in the ASF-wide parent POM.
There's also value in treating the release artifact (source tarball) as any
other maven-produced artifact (both value in using Nexus to stage releases,
and value in deploying source release tarball to Maven central for archival
and possibly for use as a dependency).

It'd be far preferable, IMO, for IPMC to drop the suffix requirement
entirely, than for any maven-based project to produce the source-tarball
independently from the production of maven artifacts. Dropping the
requirement entirely, would make it easier to use automated Maven tooling
for releases. (This automation helps ensure consistent quality, and avoid
human-error and oversight in what could otherwise be very complicated
releasing.)


> John
>
> [1]:
> http://incubator.apache.org/guides/release-java.html#best-practice-maven
> [2]: http://www.apache.org/dev/repository-faq.html
>
>
> On Tue, Dec 27, 2016 at 9:19 PM Christopher  wrote:
>
> > I think it could also be confusing for users of the Maven version didn't
> > match the IPMC released version identifier.
> >
> > If anything, it probably makes more sense to have the '-incubating' in
> the
> > groupId , since it's the endorsement of the foundation which is in the
> > interim state. The groupId typically contains the TLP name, which would
> be
> > incubator. So, org.apache.incubator? I would like that along with
> dropping
> > the incubating suffix on all artifact versions (Maven or not).
> >
> > I think it's generally confusing for users to have the suffix present,
> and
> > redundant when the artifact readme, pom metadata, or other files explain
> > it's status more clearly. It also creates excessively long file names and
> > the naming convention conflicts with other post-version identifiers, such
> > as Maven classifiers and RPM release/arch info.
> >
> > On Tue, Dec 27, 2016, 20:18 Daniel Dekany  wrote:
> >
> > > Hello,
> > >
> > > The last release of Apache FreeMarker (incubating) has these Maven
> > > coordinates:
> > >
> > > org.freemarker
> > > freemarker
> > > 2.3.25-incubating
> > >
> > > The "-incubating" in the Maven version is confusing for the users, as
> > > it looks as the version number of an unstable release, and it seems
> > > that this causes many to stick to the last non-Apache release from 1.5
> > > years ago. (See the "*" footnote if you want some more details.)
> > >
> > > As far as I know there's no explicit requirement for having
> > > "incubating" in the Maven artifact version number. So, I wonder, can
> > > we just omit "-incubating" fro

Re: Omitting "-incubating" suffix in Maven artifact version attribute for FreeMarker

[Christopher]

On Wed, Dec 28, 2016 at 8:09 AM John D. Ament  wrote:

> On Wed, Dec 28, 2016 at 5:35 AM Daniel Dekany  wrote:
>
> > Wednesday, December 28, 2016, 4:12:06 AM, Christopher wrote:
> >
> > [snip]
> > > The one complication here is that the release artifact (source tarball)
> > is
> > > most easily created with a maven project by using the
> > maven-assembly-plugin
> > > with the source tarball assembly defined in the ASF-wide parent POM.
> >
> > I'm not sure how hard it would be to set up the POM so that it
> > produces an assembly with the "-incubating" suffix even if the project
> > version doesn't contain it. Anyway, some extra release steps during
> > incubation can be better than troubling the users (developers who
> > depend on your project) with an additional groupId change or with a
> > non-standard version suffix. There are much more users than people who
> > do releases after all.
> >
>
> Do you need to add the -incubating suffix via maven?  When staging the
> release in dev, you can name the file as you like.  Even if not, maven
> assembly adds a suffix for you.  you can name your execution
> -src-incubating to include it.
>
>

It's not possible to manually rename the artifact before staging it in
Nexus, which is the most sensible thing for Maven projects to use for
staging. It is possible to rename it in SVN dist/dev, but as I said
earlier, that can also cause confusion, as in: is
"project-version-incubating.tar.gz" on the website the same as the
"project-version" I see in Maven Central and which is in the SCM tag?

Adding the suffix in some places, but not others, especially by manual
steps after altering the convenient automated tooling output, is probably
not a good idea. It's likely to cause confusion, as well as introduce
inconsistencies through human error.


>
> >
> > --
> > Thanks,
> >  Daniel Dekany
> >
> >
> > -----
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
-- 
Christopher

HTTPS project sites

[Christopher]

Hi incubating projects,

I noticed today that at least one incubating web site won't load properly
in the latest version of Chrome with the default settings using HTTPS (
https://htrace.incubator.apache.org/).

This appears to be caused by Chrome being a bit aggressive about not
loading scripts from HTTP sources when the page itself is loaded with HTTPS.

Projects may wish to check their sites to ensure that their javascript/css
resources are loading correctly when using HTTPS.

-- 
Christopher

Re: HTTPS project sites

[Christopher]

No, I did not. This issue has nothing to do with same origin policy (which
most users should never try to disable). It's about mixed content.
Accessing a site via https can give a false sense of security if the site
itself depends on non-https content.

In the past, many browsers would just show a mixed-content warning, which
most users would probably ignore. Chrome's latest behavior (and I expect
other browsers will follow eventually) tries to give a better indicator of
the degree of security a site has by not loading mixed-content by default,
and when the mixed-content is loaded, the page is explicitly marked "Not
Secure".

The end result is that project websites may not be presented to their users
in the way the developers intended.

On Fri, Jan 13, 2017 at 12:54 PM Martin Gainty  wrote:

> Hi Christopher
>
>
> did you try disabling default x-domain block for XHR request originating
> from Chrome?
>
>
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
>
>
> How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
> >
> joshuamcginnis.com
> How to enable cross-domain ajax requests in Chrome for development by
> disabling the same-origin policy.
>
>
> ?
>
> Martin
> ______
>
>
>
> 
> From: Christopher 
> Sent: Friday, January 13, 2017 12:34 PM
> To: general@incubator.apache.org
> Subject: HTTPS project sites
>
> Hi incubating projects,
>
> I noticed today that at least one incubating web site won't load properly
> in the latest version of Chrome with the default settings using HTTPS (
> https://htrace.incubator.apache.org/).
> Apache HTrace - About<https://htrace.incubator.apache.org/>
> htrace.incubator.apache.org
> Apache HTrace is an Apache Incubator project providing an open source
> framework for distributed tracing. It can be used with both standalone
> applications and libraries.
>
>
>
>
> This appears to be caused by Chrome being a bit aggressive about not
> loading scripts from HTTP sources when the page itself is loaded with
> HTTPS.
>
> Projects may wish to check their sites to ensure that their javascript/css
> resources are loading correctly when using HTTPS.
>
> --
> Christopher
>
-- 
Christopher

Re: HTTPS project sites

[Christopher]

In most cases, the project developers should just make sure their
JavaScript and CSS resources in their page point to an HTTPS version. They
don't actually need to point to the HTTP location.

On Fri, Jan 13, 2017, 20:06 Martin Gainty  wrote:

>
>
> ____
> From: Christopher 
> Sent: Friday, January 13, 2017 1:17 PM
> To: general@incubator.apache.org
> Subject: Re: HTTPS project sites
>
> No, I did not. This issue has nothing to do with same origin policy (which
> most users should never try to disable). It's about mixed content.
> Accessing a site via https can give a false sense of security if the site
> itself depends on non-https content.
>
> In the past, many browsers would just show a mixed-content warning, which
> most users would probably ignore. Chrome's latest behavior (and I expect
> other browsers will follow eventually) tries to give a better indicator of
> the degree of security a site has by not loading mixed-content by default,
> and when the mixed-content is loaded, the page is explicitly marked "Not
> Secure".
>
> The end result is that project websites may not be presented to their users
> in the way the developers intended.
>
> MG>
> http://stackoverflow.com/questions/18327314/how-to-allow-http-content-within-an-iframe-on-a-https-site
>
> MG>he mentions various strategies..twiddling http headers to https,
> screen-scraping mixed-content to aggregate on secure site and proxies
> MG> as far as proxies he mentions ngrok<https://ngrok.com/usage> and
> mitmproxy<http://mitmproxy.org/>..my personal preference is Squid
> [
> https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded
> ]<
> http://stackoverflow.com/questions/18327314/how-to-allow-http-content-within-an-iframe-on-a-https-site
> >
>
> html - How to allow http content within an iframe on a ...<
> http://stackoverflow.com/questions/18327314/how-to-allow-http-content-within-an-iframe-on-a-https-site
> >
> stackoverflow.com
> I load some HTML into an iframe but when a file referenced is using http,
> not https, I get the following error: [blocked] The page at
> {current_pagename} ran insecure ...
>
>
>
> MG>HTH
> MG>Martin-
> On Fri, Jan 13, 2017 at 12:54 PM Martin Gainty 
> wrote:
>
> > Hi Christopher
> >
> >
> > did you try disabling default x-domain block for XHR request originating
> > from Chrome?
> >
> >
> >
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
> How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
> >
> joshuamcginnis.com
> How to enable cross-domain ajax requests in Chrome for development by
> disabling the same-origin policy.
>
>
>
> >
> >
> > How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> >
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
> How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> https://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
> >
> joshuamcginnis.com
> How to enable cross-domain ajax requests in Chrome for development by
> disabling the same-origin policy.
>
>
>
> > >
> > joshuamcginnis.com
> > How to enable cross-domain ajax requests in Chrome for development by
> > disabling the same-origin policy.
> >
> >
> > ?
> >
> > Martin
> > __
> >
> >
> >
> > 
> > From: Christopher 
> > Sent: Friday, January 13, 2017 12:34 PM
> > To: general@incubator.apache.org
> > Subject: HTTPS project sites
> >
> > Hi incubating projects,
> >
> > I noticed today that at least one incubating web site won't load properly
> > in the latest version of Chrome with the default settings using HTTPS (
> > https://htrace.incubator.apache.org/).
> Apache HTrace – About<https://htrace.incubator.apache.org/>
> htrace.incubator.apache.org
> Apache HTrace is an Apache Incubator project providing an open source
> framework for distributed tracing. It can be used with both standalone
> applications and libraries.
>
>
>
> > Apache HTrace - About<https://htrace.incubator.apache.org/>
> Apache HTrace – About<https://htrace.incubator.apache.org/>
> htrace.incubator.apache.org
> Apache HTrace is an Apache Incubator project providing an open source
> framework for distributed tracing. It can be used with 

Re: HTTPS project sites

[Christopher]

While I personally would prefer ASF switch everything over to HTTPS only,
the main concern here is that projects may only be testing their sites with
HTTP, and they may not realize that their site breaks for visitors using
HTTPS. Using "https://";, or simply "//", instead of "http://"; for
javascript/css/other resources is a quick fix for most project sites. That
should get things working, regardless of whether their visitors are
visiting the project site with HTTP or HTTPS.

On Sat, Jan 14, 2017 at 12:42 AM Henri Yandell  wrote:

> We're not doing SSL-everywhere afaict; so seems that we would want to keep
> the HTTP option when in HTTP.
>
> Would love to see Infra providing a 'how many hardcoded http/https' report
> for each subdomain :)
>
> Hen
>
> On Fri, Jan 13, 2017 at 5:18 PM, Christopher  wrote:
>
> > In most cases, the project developers should just make sure their
> > JavaScript and CSS resources in their page point to an HTTPS version.
> They
> > don't actually need to point to the HTTP location.
> >
> > On Fri, Jan 13, 2017, 20:06 Martin Gainty  wrote:
> >
> > >
> > >
> > > 
> > > From: Christopher 
> > > Sent: Friday, January 13, 2017 1:17 PM
> > > To: general@incubator.apache.org
> > > Subject: Re: HTTPS project sites
> > >
> > > No, I did not. This issue has nothing to do with same origin policy
> > (which
> > > most users should never try to disable). It's about mixed content.
> > > Accessing a site via https can give a false sense of security if the
> site
> > > itself depends on non-https content.
> > >
> > > In the past, many browsers would just show a mixed-content warning,
> which
> > > most users would probably ignore. Chrome's latest behavior (and I
> expect
> > > other browsers will follow eventually) tries to give a better indicator
> > of
> > > the degree of security a site has by not loading mixed-content by
> > default,
> > > and when the mixed-content is loaded, the page is explicitly marked
> "Not
> > > Secure".
> > >
> > > The end result is that project websites may not be presented to their
> > users
> > > in the way the developers intended.
> > >
> > > MG>
> > > http://stackoverflow.com/questions/18327314/how-to-
> > allow-http-content-within-an-iframe-on-a-https-site
> > >
> > > MG>he mentions various strategies..twiddling http headers to https,
> > > screen-scraping mixed-content to aggregate on secure site and proxies
> > > MG> as far as proxies he mentions ngrok<https://ngrok.com/usage> and
> > > mitmproxy<http://mitmproxy.org/>..my personal preference is Squid
> > > [
> > > https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> > i...@2.png?v=73d79a89bded
> > > ]<
> > > http://stackoverflow.com/questions/18327314/how-to-
> > allow-http-content-within-an-iframe-on-a-https-site
> > > >
> > >
> > > html - How to allow http content within an iframe on a ...<
> > > http://stackoverflow.com/questions/18327314/how-to-
> > allow-http-content-within-an-iframe-on-a-https-site
> > > >
> > > stackoverflow.com
> > > I load some HTML into an iframe but when a file referenced is using
> http,
> > > not https, I get the following error: [blocked] The page at
> > > {current_pagename} ran insecure ...
> > >
> > >
> > >
> > > MG>HTH
> > > MG>Martin-
> > > On Fri, Jan 13, 2017 at 12:54 PM Martin Gainty 
> > > wrote:
> > >
> > > > Hi Christopher
> > > >
> > > >
> > > > did you try disabling default x-domain block for XHR request
> > originating
> > > > from Chrome?
> > > >
> > > >
> > > >
> > > https://joshuamcginnis.com/2011/02/28/how-to-disable-
> > same-origin-policy-in-chrome/
> > > How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> > > https://joshuamcginnis.com/2011/02/28/how-to-disable-
> > same-origin-policy-in-chrome/
> > > >
> > > joshuamcginnis.com
> > > How to enable cross-domain ajax requests in Chrome for development by
> > > disabling the same-origin policy.
> > >
> > >
> > >
> > > >
> > > >
> > > > How to: Disable Same-Origin Policy in Chrome | Josh McGinnis<
> > > >
> > &g

Re: HTTPS project sites

[Christopher]

Sorry if I caused confusion. I'm not requesting assistance... I'm just
trying to make the community aware of the issue, and suggesting fixes. The
HTrace page was just one example that didn't work on https.

On Sat, Jan 14, 2017 at 7:59 AM John D. Ament  wrote:

> I guess this is my confusion as well (hence my prior response).  it sounded
> like from a technical standpoint he wasn't sure how to make it protocol
> agnostic.
>
> RE HTTPS everywhere.  The only place that doesn't support HTTPS are the
> staging URLs via CMS.  Other than that, all other resources support HTTPS.
>
> John
>
> On Sat, Jan 14, 2017 at 4:02 AM Evan Hughes 
> wrote:
>
> > I see no technical reason why these external libraries cant be included
> > with https instead of http. I would rather see https:// instead of // as
> > //
> > can cause conflict when serving from a local file system as it'll assume
> > file://.
> >
> > Though I'm not sure what your proposing Christopher other than a issue
> that
> > needs to be added to htrace's jira page.
> >
> > ~ Evan
> >
> > On Sat, 14 Jan 2017 at 16:14 Christopher  wrote:
> >
> > > While I personally would prefer ASF switch everything over to HTTPS
> only,
> > > the main concern here is that projects may only be testing their sites
> > with
> > > HTTP, and they may not realize that their site breaks for visitors
> using
> > > HTTPS. Using "https://";, or simply "//", instead of "http://"; for
> > > javascript/css/other resources is a quick fix for most project sites.
> > That
> > > should get things working, regardless of whether their visitors are
> > > visiting the project site with HTTP or HTTPS.
> > >
> > > On Sat, Jan 14, 2017 at 12:42 AM Henri Yandell 
> > wrote:
> > >
> > > > We're not doing SSL-everywhere afaict; so seems that we would want to
> > > keep
> > > > the HTTP option when in HTTP.
> > > >
> > > > Would love to see Infra providing a 'how many hardcoded http/https'
> > > report
> > > > for each subdomain :)
> > > >
> > > > Hen
> > > >
> > > > On Fri, Jan 13, 2017 at 5:18 PM, Christopher 
> > > wrote:
> > > >
> > > > > In most cases, the project developers should just make sure their
> > > > > JavaScript and CSS resources in their page point to an HTTPS
> version.
> > > > They
> > > > > don't actually need to point to the HTTP location.
> > > > >
> > > > > On Fri, Jan 13, 2017, 20:06 Martin Gainty 
> > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > > From: Christopher 
> > > > > > Sent: Friday, January 13, 2017 1:17 PM
> > > > > > To: general@incubator.apache.org
> > > > > > Subject: Re: HTTPS project sites
> > > > > >
> > > > > > No, I did not. This issue has nothing to do with same origin
> policy
> > > > > (which
> > > > > > most users should never try to disable). It's about mixed
> content.
> > > > > > Accessing a site via https can give a false sense of security if
> > the
> > > > site
> > > > > > itself depends on non-https content.
> > > > > >
> > > > > > In the past, many browsers would just show a mixed-content
> warning,
> > > > which
> > > > > > most users would probably ignore. Chrome's latest behavior (and I
> > > > expect
> > > > > > other browsers will follow eventually) tries to give a better
> > > indicator
> > > > > of
> > > > > > the degree of security a site has by not loading mixed-content by
> > > > > default,
> > > > > > and when the mixed-content is loaded, the page is explicitly
> marked
> > > > "Not
> > > > > > Secure".
> > > > > >
> > > > > > The end result is that project websites may not be presented to
> > their
> > > > > users
> > > > > > in the way the developers intended.
> > > > > >
> > > > > > MG>
> > > > > > http://stackoverflow.com/questions/18327314/how-to-
> > > > > allow-http-content-within-an-iframe-on

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:

> On 6 June 2017 at 21:15, Keith Turner  wrote:
> > Dear IPMC,
> >
> > Please vote for the following release candidate of Apache Fluo
> > 1.1.0-incubating.
> >
> > PPMC vote thread:
> >
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >
> > Staged dist artifacts:
> >
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
>
> The hashes need to be in individual files, like the signature (.asc)
> [You can probably copy the corresponding ones from the Maven repo.]
>
> AFAIK the MD5SUM and SHA1SUM files should not be present.
>
> I'm not sure the .gitignore files should be there.
>
>

I believe the *SUM files have been discussed before. I do not believe it to
be an issue, as INFRA excludes these from mirroring in the same way as
other files, and they are convenient.

I'm not sure what .gitignore files you're referring to. There are some in
the directories above the RC directory, to support using SVN with git-svn
(git ignores empty directories; the .gitignore file preserves them). There
aren't any inside the 1.1.0-incubating-rc1 directory, though.



> > Staged Maven repository:
> > https://repository.apache.org/content/repositories/orgapachefluo-1017/
> >
> > Signing KEYS:
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (fingerprint for this release: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >
> > Git repo:
> > https://gitbox.apache.org/repos/asf/incubator-fluo
> > (branch: 1.1.0-incubating-rc1,
> > commit: ad8ee492e2f435405f98d825781098c55186f4fb)
> >
> > This vote will end on Fri Jun  9 20:30:00 UTC 2017
> > (Fri Jun  9 16:30:00 EDT 2017 / Fri Jun  9 13:30:00 PDT 2017)
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:

> On 6 June 2017 at 23:25, Christopher  wrote:
> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
> >
> >> On 6 June 2017 at 21:15, Keith Turner  wrote:
> >> > Dear IPMC,
> >> >
> >> > Please vote for the following release candidate of Apache Fluo
> >> > 1.1.0-incubating.
> >> >
> >> > PPMC vote thread:
> >> >
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >
> >> > Staged dist artifacts:
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >>
> >> The hashes need to be in individual files, like the signature (.asc)
> >> [You can probably copy the corresponding ones from the Maven repo.]
> >>
> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >>
> >> I'm not sure the .gitignore files should be there.
> >>
> >>
> >
> > I believe the *SUM files have been discussed before. I do not believe it
> to
> > be an issue, as INFRA excludes these from mirroring in the same way as
> > other files, and they are convenient.
>
> But the individual has files are still required.
>
>
Required by what policy?


> > I'm not sure what .gitignore files you're referring to. There are some in
> > the directories above the RC directory, to support using SVN with git-svn
> > (git ignores empty directories; the .gitignore file preserves them).
> There
> > aren't any inside the 1.1.0-incubating-rc1 directory, though.
>
> I'm referring to the ones in the parent directories.
>
> Since the dist tree is SVN only (and will remain that way) there is no
> need for them.
>
>

They are needed by git-svn in order to preserve the empty directory in the
clone. They can be ignored for the purposes of this vote, since they aren't
even in the same directory as the release candidate files, and will not be
included in the `svn mv` upon a successful vote.



> >
> >
> >> > Staged Maven repository:
> >> >
> https://repository.apache.org/content/repositories/orgapachefluo-1017/
> >> >
> >> > Signing KEYS:
> >> > https://www.apache.org/dist/incubator/fluo/KEYS
> >> > (fingerprint for this release:
> CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >> >
> >> > Git repo:
> >> > https://gitbox.apache.org/repos/asf/incubator-fluo
> >> > (branch: 1.1.0-incubating-rc1,
> >> > commit: ad8ee492e2f435405f98d825781098c55186f4fb)
> >> >
> >> > This vote will end on Fri Jun  9 20:30:00 UTC 2017
> >> > (Fri Jun  9 16:30:00 EDT 2017 / Fri Jun  9 13:30:00 PDT 2017)
> >> >
> >> > -
> >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> > For additional commands, e-mail: general-h...@incubator.apache.org
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

On Tue, Jun 6, 2017 at 6:47 PM sebb  wrote:

> On 6 June 2017 at 23:38, Christopher  wrote:
> > On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:
> >
> >> On 6 June 2017 at 23:25, Christopher  wrote:
> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
> >> >
> >> >> On 6 June 2017 at 21:15, Keith Turner  wrote:
> >> >> > Dear IPMC,
> >> >> >
> >> >> > Please vote for the following release candidate of Apache Fluo
> >> >> > 1.1.0-incubating.
> >> >> >
> >> >> > PPMC vote thread:
> >> >> >
> >> >>
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >> >
> >> >>
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >> >
> >> >> > Staged dist artifacts:
> >> >> >
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >> >>
> >> >> The hashes need to be in individual files, like the signature (.asc)
> >> >> [You can probably copy the corresponding ones from the Maven repo.]
> >> >>
> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >> >>
> >> >> I'm not sure the .gitignore files should be there.
> >> >>
> >> >>
> >> >
> >> > I believe the *SUM files have been discussed before. I do not believe
> it
> >> to
> >> > be an issue, as INFRA excludes these from mirroring in the same way as
> >> > other files, and they are convenient.
> >>
> >> But the individual has files are still required.
> >>
> >>
> > Required by what policy?
> >
>
> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
>
>

Thanks.

That's interesting. The current wording seems like a technical requirement
for the mirror distribution process. It seems like the intent (though, hard
to know for sure) was to follow a pattern that would ensure hashes aren't
mirrored. However, it is currently inconsistent with the actual behavior of
the mirror distribution process and also seems to apply to all other
infra-supported channels like Nexus. It also seems to be regularly
violated, since there are a *LOT* of projects which use variants, such as
".sha1" or ".sha256" or ".sha512" or ".mds" in dist/release. Also, every
Maven artifact deployed to Nexus is also in violation. That's not an excuse
to violate it again, of course... but it's a strong indication that the
page isn't accurately documenting the actual policy that INFRA enforces for
distribution through ASF infra channels.

Perhaps VP Infra would be willing to consider a change to the wording so it
more closely aligns with the actual requirements of the mirroring process.
I don't recall who that is at the moment. David Nalley, according to
https://home.apache.org/phonebook.html?pmc=infrastructure ? Is that right?
Or is it Greg Stein
(/foundation/officers/personnel-duties/infra-admin.txt)? Or should I just
start a conversation on an infra list somewhere? Or file a JIRA? I don't
know the best method to contact VP Infra to request update/clarification on
this policy issue.



> >> > I'm not sure what .gitignore files you're referring to. There are
> some in
> >> > the directories above the RC directory, to support using SVN with
> git-svn
> >> > (git ignores empty directories; the .gitignore file preserves them).
> >> There
> >> > aren't any inside the 1.1.0-incubating-rc1 directory, though.
> >>
> >> I'm referring to the ones in the parent directories.
> >>
> >> Since the dist tree is SVN only (and will remain that way) there is no
> >> need for them.
> >>
> >>
> >
> > They are needed by git-svn in order to preserve the empty directory in
> the
> > clone. They can be ignored for the purposes of this vote, since they
> aren't
> > even in the same directory as the release candidate files, and will not
> be
> > included in the `svn mv` upon a successful vote.
>
> OK, so long as they are not added to the dist/release directory area.
>
> >
> >
> >> >
> >> >
> >> >> > Staged Maven repository:
> >> >> >
> >> https://repository.apache.org/content/rep

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

I've updated the svn staging area to comply with the currently documented
policy.

On Tue, Jun 6, 2017 at 8:59 PM Christopher  wrote:

> On Tue, Jun 6, 2017 at 6:47 PM sebb  wrote:
>
>> On 6 June 2017 at 23:38, Christopher  wrote:
>> > On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:
>> >
>> >> On 6 June 2017 at 23:25, Christopher  wrote:
>> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
>> >> >
>> >> >> On 6 June 2017 at 21:15, Keith Turner  wrote:
>> >> >> > Dear IPMC,
>> >> >> >
>> >> >> > Please vote for the following release candidate of Apache Fluo
>> >> >> > 1.1.0-incubating.
>> >> >> >
>> >> >> > PPMC vote thread:
>> >> >> >
>> >> >>
>> >>
>> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
>> >> >> >
>> >> >>
>> >>
>> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
>> >> >> >
>> >> >> > Staged dist artifacts:
>> >> >> >
>> >> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
>> >> >>
>> >> >> The hashes need to be in individual files, like the signature (.asc)
>> >> >> [You can probably copy the corresponding ones from the Maven repo.]
>> >> >>
>> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
>> >> >>
>> >> >> I'm not sure the .gitignore files should be there.
>> >> >>
>> >> >>
>> >> >
>> >> > I believe the *SUM files have been discussed before. I do not
>> believe it
>> >> to
>> >> > be an issue, as INFRA excludes these from mirroring in the same way
>> as
>> >> > other files, and they are convenient.
>> >>
>> >> But the individual has files are still required.
>> >>
>> >>
>> > Required by what policy?
>> >
>>
>> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
>>
>>
>
> Thanks.
>
> That's interesting. The current wording seems like a technical requirement
> for the mirror distribution process. It seems like the intent (though, hard
> to know for sure) was to follow a pattern that would ensure hashes aren't
> mirrored. However, it is currently inconsistent with the actual behavior of
> the mirror distribution process and also seems to apply to all other
> infra-supported channels like Nexus. It also seems to be regularly
> violated, since there are a *LOT* of projects which use variants, such as
> ".sha1" or ".sha256" or ".sha512" or ".mds" in dist/release. Also, every
> Maven artifact deployed to Nexus is also in violation. That's not an excuse
> to violate it again, of course... but it's a strong indication that the
> page isn't accurately documenting the actual policy that INFRA enforces for
> distribution through ASF infra channels.
>
> Perhaps VP Infra would be willing to consider a change to the wording so
> it more closely aligns with the actual requirements of the mirroring
> process. I don't recall who that is at the moment. David Nalley, according
> to https://home.apache.org/phonebook.html?pmc=infrastructure ? Is that
> right? Or is it Greg Stein
> (/foundation/officers/personnel-duties/infra-admin.txt)? Or should I just
> start a conversation on an infra list somewhere? Or file a JIRA? I don't
> know the best method to contact VP Infra to request update/clarification on
> this policy issue.
>
>
>
>> >> > I'm not sure what .gitignore files you're referring to. There are
>> some in
>> >> > the directories above the RC directory, to support using SVN with
>> git-svn
>> >> > (git ignores empty directories; the .gitignore file preserves them).
>> >> There
>> >> > aren't any inside the 1.1.0-incubating-rc1 directory, though.
>> >>
>> >> I'm referring to the ones in the parent directories.
>> >>
>> >> Since the dist tree is SVN only (and will remain that way) there is no
>> >> need for them.
>> >>
>> >>
>> >
>> > They are needed by git-svn in order to prese

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

(FWIW, http://www.apache.org/dev/release-publishing.html#distribution_dist
documents
file conventions from INFRA-8959, but not yet INFRA-13756, but all 3 are
out of sync with the policy linked previously in this thread. It's a very
confusing situation. I've emailed private@infra, David, and Greg, to
request an update to the policy to bring everything in line with current
mirroring system requirements. I will update this list in a new thread
if/when I hear back.)

On Wed, Jun 7, 2017 at 4:34 PM Josh Elser  wrote:

> +1 (binding)
>
> Forwarded from the ppmc VOTE thread.
>
> On 6/6/17 4:15 PM, Keith Turner wrote:
> > Dear IPMC,
> >
> > Please vote for the following release candidate of Apache Fluo
> > 1.1.0-incubating.
> >
> > PPMC vote thread:
> >
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >
> > Staged dist artifacts:
> >
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >
> > Staged Maven repository:
> > https://repository.apache.org/content/repositories/orgapachefluo-1017/
> >
> > Signing KEYS:
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (fingerprint for this release: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >
> > Git repo:
> > https://gitbox.apache.org/repos/asf/incubator-fluo
> > (branch: 1.1.0-incubating-rc1,
> > commit: ad8ee492e2f435405f98d825781098c55186f4fb)
> >
> > This vote will end on Fri Jun  9 20:30:00 UTC 2017
> > (Fri Jun  9 16:30:00 EDT 2017 / Fri Jun  9 13:30:00 PDT 2017)
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

On Wed, Jun 7, 2017 at 5:28 PM sebb  wrote:

> On 7 June 2017 at 01:59, Christopher  wrote:
> > On Tue, Jun 6, 2017 at 6:47 PM sebb  wrote:
> >
> >> On 6 June 2017 at 23:38, Christopher  wrote:
> >> > On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:
> >> >
> >> >> On 6 June 2017 at 23:25, Christopher  wrote:
> >> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
> >> >> >
> >> >> >> On 6 June 2017 at 21:15, Keith Turner  wrote:
> >> >> >> > Dear IPMC,
> >> >> >> >
> >> >> >> > Please vote for the following release candidate of Apache Fluo
> >> >> >> > 1.1.0-incubating.
> >> >> >> >
> >> >> >> > PPMC vote thread:
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >> >> >
> >> >> >> > Staged dist artifacts:
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >> >> >>
> >> >> >> The hashes need to be in individual files, like the signature
> (.asc)
> >> >> >> [You can probably copy the corresponding ones from the Maven
> repo.]
> >> >> >>
> >> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >> >> >>
> >> >> >> I'm not sure the .gitignore files should be there.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > I believe the *SUM files have been discussed before. I do not
> believe
> >> it
> >> >> to
> >> >> > be an issue, as INFRA excludes these from mirroring in the same
> way as
> >> >> > other files, and they are convenient.
> >> >>
> >> >> But the individual has files are still required.
> >> >>
> >> >>
> >> > Required by what policy?
> >> >
> >>
> >> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
> >>
> >>
> >
> > Thanks.
> >
> > That's interesting. The current wording seems like a technical
> requirement
> > for the mirror distribution process. It seems like the intent (though,
> hard
> > to know for sure) was to follow a pattern that would ensure hashes aren't
> > mirrored.
>
> AIUI that is partly the case.
> AFAIK there's also the expectation that consumers will be able to use
> a standard name for the hashes and sigs.
>
>

I wouldn't have thought INFRA would be in the business of managing consumer
expectations. Seems like a PMC responsibility, at the individual community
level, to me.



> > However, it is currently inconsistent with the actual behavior of
> > the mirror distribution process and also seems to apply to all other
> > infra-supported channels like Nexus. It also seems to be regularly
> > violated, since there are a *LOT* of projects which use variants, such as
> > ".sha1" or ".sha256" or ".sha512" or ".mds" in dist/release.
>
> Does not make it right; AFAIK many such variants are excluded from synch.
>
>

In anticipation of this response, I've already conceded this point. ;)
As I said, it's merely a strong indication that the page isn't accurately
documenting the policy being enforced.


> > Also, every
> > Maven artifact deployed to Nexus is also in violation.
>
> Nexus (i.e. staging for the Maven repo) has separate rules.
>
>
The policy you cite specifically says "Every artifact distributed to the
public through Apache channels". The wording doesn't allow for differences
between system-specific channels.

If we're going by system-specific guidance, then I don't understand your
original objection, because SHA1SUM and MD5SUM files are explicitly
mentioned in the system-specific guidance for "normal distribution" through
the mirrors
http://www.apache.org/dev/release-publishing.html#distribution_dist , just
as .sha1 is explicitly mentioned in the Maven publica

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

Ping IPMC to take a look at this release candidate from Fluo. It currently
has only one +1 from carried over from PPMC vote by mentor, and no other
votes.

On Wed, Jun 7, 2017 at 6:48 PM sebb  wrote:

> On 7 June 2017 at 23:36, Christopher  wrote:
> > On Wed, Jun 7, 2017 at 5:28 PM sebb  wrote:
> >
> >> On 7 June 2017 at 01:59, Christopher  wrote:
> >> > On Tue, Jun 6, 2017 at 6:47 PM sebb  wrote:
> >> >
> >> >> On 6 June 2017 at 23:38, Christopher  wrote:
> >> >> > On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:
> >> >> >
> >> >> >> On 6 June 2017 at 23:25, Christopher  wrote:
> >> >> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
> >> >> >> >
> >> >> >> >> On 6 June 2017 at 21:15, Keith Turner 
> wrote:
> >> >> >> >> > Dear IPMC,
> >> >> >> >> >
> >> >> >> >> > Please vote for the following release candidate of Apache
> Fluo
> >> >> >> >> > 1.1.0-incubating.
> >> >> >> >> >
> >> >> >> >> > PPMC vote thread:
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >> >> >> >
> >> >> >> >> > Staged dist artifacts:
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >> >> >> >>
> >> >> >> >> The hashes need to be in individual files, like the signature
> >> (.asc)
> >> >> >> >> [You can probably copy the corresponding ones from the Maven
> >> repo.]
> >> >> >> >>
> >> >> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >> >> >> >>
> >> >> >> >> I'm not sure the .gitignore files should be there.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> > I believe the *SUM files have been discussed before. I do not
> >> believe
> >> >> it
> >> >> >> to
> >> >> >> > be an issue, as INFRA excludes these from mirroring in the same
> >> way as
> >> >> >> > other files, and they are convenient.
> >> >> >>
> >> >> >> But the individual has files are still required.
> >> >> >>
> >> >> >>
> >> >> > Required by what policy?
> >> >> >
> >> >>
> >> >> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
> >> >>
> >> >>
> >> >
> >> > Thanks.
> >> >
> >> > That's interesting. The current wording seems like a technical
> >> requirement
> >> > for the mirror distribution process. It seems like the intent (though,
> >> hard
> >> > to know for sure) was to follow a pattern that would ensure hashes
> aren't
> >> > mirrored.
> >>
> >> AIUI that is partly the case.
> >> AFAIK there's also the expectation that consumers will be able to use
> >> a standard name for the hashes and sigs.
> >>
> >>
> >
> > I wouldn't have thought INFRA would be in the business of managing
> consumer
> > expectations. Seems like a PMC responsibility, at the individual
> community
> > level, to me.
> >
> >
> >> > However, it is currently inconsistent with the actual behavior of
> >> > the mirror distribution process and also seems to apply to all other
> >> > infra-supported channels like Nexus. It also seems to be regularly
> >> > violated, since there are a *LOT* of projects which use variants,
> such as
> >> > ".sha1" or ".sha

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

Here's a good blog post on how to add an additional identity/email to the
existing gpg key, if Keith wished to add his apache email address. It's not
much effort, and it wouldn't change the signatures at all. It would just
link the existing signature to the apache identity.
https://www.katescomment.com/how-to-add-additional-email-addresses-to-your-gpg-identity/

Thanks for pointing out the date in the main NOTICE file. That was brought
up on the PPMC vote also, with the intent to fix next time. We've
double-checked that it's the only one. I checked that the NOTICE files in
the jars are good (2016-2017).

On Sat, Jun 10, 2017 at 6:25 PM Justin Mclean 
wrote:

> Hi,
>
> +1 binding
>
> I checked:
> - artefacts contain incubating
> - signatures and hashes good
> - no unexpected binary files in source release
> - LICENSE is good (no 3rd party bundled software)
> - NOTICE is also fine but please fix the year for the next release
> - can compile from source
>
> Next it would be better to sign the artefacts with an apache email address.
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[DISCUSS] Fluo graduation as TLP

[Christopher]

Greetings Incubator,

The Fluo podling has decided to pursue graduation to a TLP. The result of
the internal PPMC vote is at [1] (apologies that it occurred on our private
list instead of on our dev list; the discuss thread [2] which preceded it
did occur on the dev list). Our podling status page has recently been
updated and can be found here[3].

Below, you can view the proposed TLP resolution which we'd like to present
to the board with the support of the IPMC, after sufficient discussion here
and subsequent IPMC vote.

[1]:
https://lists.apache.org/thread.html/04a9de260fcd14b184ae7a8b725e348e13ee4ad10e3057a6a404732c@%3Cprivate.fluo.apache.org%3E
[2]:
https://lists.apache.org/thread.html/3164d77ea18c3e36ce215ab4a07b2cb80cf9c49c2503ef5d1defbdde@%3Cdev.fluo.apache.org%3E
[3]: https://incubator.apache.org/projects/fluo

**
Establish the Apache Fluo Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to the storage and incremental processing of large data sets.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Fluo Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Fluo Project be and hereby is responsible for
the creation and maintenance of software related to the storage and
incremental processing of large data sets; and be it further

RESOLVED, that the office of "Vice President, Apache Fluo" be and hereby
is created, the person holding such office to serve at the direction of
the Board of Directors as the chair of the Apache Fluo Project, and to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Fluo Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Fluo Project:

* Billie Rinaldi 
* Chris McTague 
* Christopher Tubbs 
* Corey J. Nolet 
* Drew Farris 
* Josh Elser 
* Keith Turner 
* Mike Walch 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Keith Turner be appointed
to the office of Vice President, Apache Fluo, to serve in accordance
with and subject to the direction of the Board of Directors and the
Bylaws of the Foundation until death, resignation, retirement, removal
or disqualification, or until a successor is appointed; and be it
further

RESOLVED, that the initial Apache Fluo PMC be and hereby is tasked with
the creation of a set of bylaws intended to encourage open development
and increased participation in the Apache Fluo Project; and be it
further

RESOLVED, that the Apache Fluo Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator Fluo podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Fluo podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Re: [DISCUSS] Fluo graduation as TLP

[Christopher]

On Mon, Jul 3, 2017 at 4:23 PM John D. Ament  wrote:

> Oh hmm did a bit more digging.
>
> Looks like you did add someone, but I guess due to timing it was missed in
> the last board report? Then nevermind, ignore my 2nd bullet point.
>
>
Correct. This was due to timing. If we don't graduate by then, the new
committer will appear on our next report. (And will appear on our first
board report if we do graduate.) Our podling status page does include him,
however.


> John
>
> On Mon, Jul 3, 2017 at 4:15 PM John D. Ament 
> wrote:
>
> > Hi Christopher,
> >
> > Thanks for the heads up.  A few nits on my part, but overall I would be
> > happy to see Fluo graduate.  When reading my notes, please also consult
> the
> > graduation guide at [1].
> >
> > - The discussion and vote should have happened on your public dev list,
> > not private.  It's good that at least discussion happened publicly, and
> the
> > actual vote isn't required so it's not a big deal.
> > - I don't see any sign that you added new committers or PPMC members
> since
> > incubating.  See also [2].  I don't see that as a show stopper, as it
> looks
> > like a diverse group.
>

It's not as diverse as we'd like. We recognize this and really want to do
better. This was raised in our DISCUSS thread, but it seems agreed that
remaining in Incubation is not going to help this situation much. It will
be something we will continue to work on, regardless, and something we'd
include in our board reports as a TLP.


> > - Of the proposed PMC, how many are actively committing to Fluo?  Was
> > there an ask at any point to see who was still interested?
>

At least three are actively committing. An additional one (myself) helps
out more with code reviews, build system maintenance, bug reports, and
releases rather than coding. At least one of the mentors was active with
reading issues and participating in discussions. Two others have mainly
been acting only as mentors.

I'm not sure I understand your second question.


> > - Only one mentor voted on the graduation.  Would be great to see if the
> > other mentors are equally on board.
> >
>

I don't want to speak for them, but to summarize what's in the podling
VOTE/DISCUSS threads: only one formally voted in the VOTE thread, but one
more gave their enthusiastic +1 in the DISCUSS thread. The third expressed
some hesitation based on the size of the community (see my response about
diversity/size above), but seemed to accept the argument I made in that
thread for us continuing to work on this and include our progress in our
regular board reports as a TLP.


> > John
> >
> > [1]: http://incubator.apache.org/guides/graduation.html#toplevel
> > [2]: https://whimsy.apache.org/board/minutes/Fluo
> >
> >
> > On Mon, Jul 3, 2017 at 2:12 PM Christopher  wrote:
> >
> >> Greetings Incubator,
> >>
> >> The Fluo podling has decided to pursue graduation to a TLP. The result
> of
> >> the internal PPMC vote is at [1] (apologies that it occurred on our
> >> private
> >> list instead of on our dev list; the discuss thread [2] which preceded
> it
> >> did occur on the dev list). Our podling status page has recently been
> >> updated and can be found here[3].
> >>
> >> Below, you can view the proposed TLP resolution which we'd like to
> present
> >> to the board with the support of the IPMC, after sufficient discussion
> >> here
> >> and subsequent IPMC vote.
> >>
> >> [1]:
> >>
> >>
> https://lists.apache.org/thread.html/04a9de260fcd14b184ae7a8b725e348e13ee4ad10e3057a6a404732c@%3Cprivate.fluo.apache.org%3E
> >> [2]:
> >>
> >>
> https://lists.apache.org/thread.html/3164d77ea18c3e36ce215ab4a07b2cb80cf9c49c2503ef5d1defbdde@%3Cdev.fluo.apache.org%3E
> >> [3]: https://incubator.apache.org/projects/fluo
> >>
> >> **
> >> Establish the Apache Fluo Project
> >>
> >> WHEREAS, the Board of Directors deems it to be in the best interests of
> >> the Foundation and consistent with the Foundation's purpose to establish
> >> a Project Management Committee charged with the creation and maintenance
> >> of open-source software, for distribution at no charge to the public,
> >> related to the storage and incremental processing of large data sets.
> >>
> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> >> (PMC), to be known as the "Apache Fluo Project", be and hereby is
> >> established pursuant to Bylaws of the Foun

Re: [DISCUSS] Fluo graduation as TLP

[Christopher]

On Wed, Jul 5, 2017 at 1:52 PM Dave Fisher  wrote:

> Hi Josh,
>
> I have some questions:
>
> > On Jul 5, 2017, at 10:18 AM, Josh Elser  wrote:
> >
> > As a mentor, I consciously avoided an explicit "+1" until we got some
> IPMC discussion. Let me expand:
> >
> > The current members of Fluo are great, get the Apache Way, and are
> self-sufficient. I have no concerns over them operating as a TLP -- I think
> they are ready. However, they have only added a single committer and I see
> none in the pipeline -- Fluo is defined by the current committers.
>
> (1) Seems to be a niche project as you state below which is just within
> the range of 5 contributors. Am I wrong?
>
> > My hesitation is balancing the Incubators goal of "pushing podlings to
> graduate" and ensuring adequate diversity in the podling. This is
> especially difficult for Fluo as they're "niche on niche" (it's a difficult
> dist-sys problem/software, and not many people use the tech they're
> building on top of given my view of the world).
> >
> > I realize that this discussion could easily spiral out of control,
> turning into some meta-discussion about Incubator goals. I want to avoid
> that.
> >
> > I'm looking for some feelings from other IPMC folks about how to
> approach the Fluo podling given their specific circumstances. If other
> people are also hesitant, I would also be interested in suggestions about
> what we would concretely change (because I don't know what to suggest that
> "fix" the diversity issue for them that isn't changing the core of their
> project). If people aren't worried, I'm happy to give an explicit +1.
>
> (2) Has any consideration been given to becoming a project within
> Accumulo? Or are the goals of Fluo distinct from and not wholly dependent
> on Accumulo?
>
>
I'd like to answer this number (2): This possibility was mentioned by me
after one of our previous status reports as a discussion I'd like to have
on the list. However, I never raised it again on the list to formally
discuss. There's a few potential reasons why I now think that might not
work well, and why I never brought it up again (and probably why nobody
raised it with the Accumulo PMC):

1. The committers do overlap (all but one Fluo PPMC/committer is also an
Accumulo PMC/committer), but Accumulo's PMC is much larger than Fluo's
PPMC. It would not make sense for the Fluo PPMC to grant majority control
to an Accumulo PMC which does not necessarily share the consensus direction
that Fluo is headed. I'm sure Fluo would be happy to incrementally onboard
Accumulo developers as they began participating in Fluo development, but
bringing them in without vetting their merits from the Fluo team's
perspective seems like a bad idea. The Fluo team would probably prefer
decide on the merits of new committers/PMC based on their contributions to
Fluo, rather than automatically inherit any committers from another project.

2. While Fluo is currently implemented on Accumulo, it is not necessarily
the intent for it to remain this way. Under an Accumulo PMC, it is likely
this coupling would solidify, rather than be abstracted. When Fluo was
proposed to the incubator, it was mentioned that we'd be willing to accept
contributions to expand Fluo's feature set so that it works on other
databases. The proposed TLP resolution reflects this willingness to expand
beyond Accumulo by not mentioning Accumulo in its mission statement.

3. Accumulo uses a JIRA-based workflow with pull requests on GitHub and
C-T-R. Fluo is using GitBox with R-T-C. The workflows are very different.
Accumulo's existing bylaws explicitly contradict Fluo's own workflow that
the developers seem comfortable with.

4. Speaking as an Accumulo PMC member, I don't know that I'd want to set a
precedence for accepting Accumulo-related projects as subprojects of
Accumulo, simply because it can be a bit of scope creep for Accumulo. The
Accumulo PMC has already been approached to accept several other extensions
to Accumulo as subprojects from "drive-by" sources who (from appearances)
simply want to offload the maintenance work without community
participation. I can't speak for the rest of the Accumulo PMC, but it seems
preferable to me that the Accumulo PMC protect itself from such DOA code
dumps by leaning towards resisting subprojects (though, having gone through
Incubation can be proof that the code is not going to be DOA). Speaking as
a Fluo PPMC member, I would not want to burden the Accumulo PMC with the
responsibility to regularly evaluate whether to accept bulk code as
subprojects, by opening those flood gates and distracting the PMC from its
primary responsibilities to its existing code.



> (3) 

Re: [DISCUSS] Fluo graduation as TLP

[Christopher]

I used the whimsy tool to generate the draft proposal included in this
thread. Very convenient!
My intention was to let this thread sit for the weekend, and start a VOTE
thread on Monday if no new discussion activity.

On Sun, Jul 9, 2017 at 8:38 AM John D. Ament  wrote:

> Will the podling be progressing on a vote in time for the next board report
> (7/19)? Please make sure you draft your proposal.  You can take a sample
> draft from https://whimsy.apache.org/roster/ppmc/fluo (it's all the way at
> the bottom)
>
> On Thu, Jul 6, 2017 at 10:55 AM Josh Elser  wrote:
>
> > Thanks, John. Consider this mentor +1 then.
> >
> > On 7/5/17 7:03 PM, John D. Ament wrote:
> > > For what it's worth, I have no concerns with Fluo's graduation based on
> > the
> > > conversation here.
> > >
> > > John
> > >
> > > On Wed, Jul 5, 2017 at 7:02 PM Josh Elser  wrote:
> > >
> > >>
> > >>
> > >> On 7/5/17 1:51 PM, Dave Fisher wrote:
> > >>> Hi Josh,
> > >>>
> > >>> I have some questions:
> > >>>
> >  On Jul 5, 2017, at 10:18 AM, Josh Elser  wrote:
> > 
> >  As a mentor, I consciously avoided an explicit "+1" until we got
> some
> > >> IPMC discussion. Let me expand:
> > 
> >  The current members of Fluo are great, get the Apache Way, and are
> > >> self-sufficient. I have no concerns over them operating as a TLP -- I
> > think
> > >> they are ready. However, they have only added a single committer and I
> > see
> > >> none in the pipeline -- Fluo is defined by the current committers.
> > >>>
> > >>> (1) Seems to be a niche project as you state below which is just
> within
> > >> the range of 5 contributors. Am I wrong?
> > >>
> > >> Yup, that sounds about right. I'm notice three of them being the most
> > >> active, but I tend to not watch that closely.
> > >>
> >  My hesitation is balancing the Incubators goal of "pushing podlings
> to
> > >> graduate" and ensuring adequate diversity in the podling. This is
> > >> especially difficult for Fluo as they're "niche on niche" (it's a
> > difficult
> > >> dist-sys problem/software, and not many people use the tech they're
> > >> building on top of given my view of the world).
> > 
> >  I realize that this discussion could easily spiral out of control,
> > >> turning into some meta-discussion about Incubator goals. I want to
> avoid
> > >> that.
> > 
> >  I'm looking for some feelings from other IPMC folks about how to
> > >> approach the Fluo podling given their specific circumstances. If other
> > >> people are also hesitant, I would also be interested in suggestions
> > about
> > >> what we would concretely change (because I don't know what to suggest
> > that
> > >> "fix" the diversity issue for them that isn't changing the core of
> their
> > >> project). If people aren't worried, I'm happy to give an explicit +1.
> > >>>
> > >>> (2) Has any consideration been given to becoming a project within
> > >> Accumulo? Or are the goals of Fluo distinct from and not wholly
> > dependent
> > >> on Accumulo?
> > >>>
> > >>> (3) Corollary - it seems a large number of Fluo Initial Committers
> were
> > >> also Accumulo PMC. (I not intentionally rehashing any prior
> > conversation.)
> > >>>
> > >>
> > >> Will leave Christopher's response to (thoroughly) answer this ;)
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Fluo graduation as TLP

[Christopher]

As a project which was born and raised on GitHub, Fluo makes very heavy use
of the issue tracker for day to day decision making and asyncronous
discussions, using GitHub issues and pull requests. We're a R-t-C
community, and a lot of that discussion occurs during code reviews on the
issue tracker. We've found that works very well. For ASF tracking purposes,
it relies on infra services to CC the notifications list. New users can get
up to speed by looking at the history there, but it's probably much easier
to dive in to the documentation on the website and browse the discussions
on the issue tracker threads.

On Mon, Jul 10, 2017, 07:34 Bertrand Delacretaz 
wrote:

> Hi,
>
> It looks like Fluo is indeed ready to graduate but I have a question
> about its dev list usage.
>
> I had a look at the Fluo dev list archive,
> https://lists.apache.org/list.html?d...@fluo.apache.org
>
> There's very little going on there in terms of technical discussions
> and decisions, most of the traffic (and that's not much) seems to be
> about project governance topics.
>
> Can someone from Fluo comment on that vs. "if it didn't happen on the
> dev list it didn't happen" ?
>
> Are open asynchronous discussions happening elsewhere, and how do you
> see newcomers getting up to speed?
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[VOTE] Recommend Apache Fluo graduation as TLP to Board

[Christopher]

Hello IPMC,

The recent DISCUSS thread on the topic of Fluo's graduation has been open
for at least 72 hours, and I believe all questions have been answered and
issues addressed at this point.

With the discussion having settled down, I would now like to call for a
recommendation VOTE to present the ASF board with the following resolution
to graduate from incubation and establish Apache Fluo as a top-level
project (TLP).

Incubator DISCUSS thread:
https://lists.apache.org/thread.html/214424f03d6f7b47f3abc1e3da772627390a07960daa8b95365380bc@%3Cgeneral.incubator.apache.org%3E
Fluo PPMC DISCUSS thread:
https://lists.apache.org/thread.html/3164d77ea18c3e36ce215ab4a07b2cb80cf9c49c2503ef5d1defbdde@%3Cdev.fluo.apache.org%3E
Fluo PPMC internal VOTE thread:
https://lists.apache.org/thread.html/04a9de260fcd14b184ae7a8b725e348e13ee4ad10e3057a6a404732c@%3Cprivate.fluo.apache.org%3E
Fluo Podling Status page: https://incubator.apache.org/projects/fluo

Please vote on whether to recommend the following graduation resolution to
the ASF Board.

[  ]  +1, In favor of recommending the following graduation resolution to
the ASF Board to establish Apache Fluo as a TLP
[  ]  +0, Neither opposed to, nor in favor of, recommending the following
graduation resolution to the Board
[  ]  -1, Opposed to recommending the following graduation resolution to
the Board

This VOTE will be open for at least 72 hours.

***Resolution:

Establish the Apache Fluo Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to the storage and incremental processing of large data sets.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Fluo Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Fluo Project be and hereby is responsible for
the creation and maintenance of software related to the storage and
incremental processing of large data sets; and be it further

RESOLVED, that the office of "Vice President, Apache Fluo" be and hereby
is created, the person holding such office to serve at the direction of
the Board of Directors as the chair of the Apache Fluo Project, and to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Fluo Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Fluo Project:

* Billie Rinaldi 
* Chris McTague 
* Christopher Tubbs 
* Corey J. Nolet 
* Drew Farris 
* Josh Elser 
* Keith Turner 
* Mike Walch 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Keith Turner be appointed
to the office of Vice President, Apache Fluo, to serve in accordance
with and subject to the direction of the Board of Directors and the
Bylaws of the Foundation until death, resignation, retirement, removal
or disqualification, or until a successor is appointed; and be it
further

RESOLVED, that the initial Apache Fluo PMC be and hereby is tasked with
the creation of a set of bylaws intended to encourage open development
and increased participation in the Apache Fluo Project; and be it
further

RESOLVED, that the Apache Fluo Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator Fluo podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Fluo podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

[RESULT][VOTE] Recommend Apache Fluo graduation as TLP to Board

[Christopher]

Since at least 72 hours have elapsed, the voting period has now concluded,
and the vote passes.

5 +1 (binding) votes:
* Josh Elser
* Billie Rinaldi
* John D. Ament
* Bertrand Delacrétaz
* David Fisher

Additionally, 1 +1 (non-binding) vote:
* Pierre Smits

Thanks to all!

Permalink:
https://lists.apache.org/thread.html/f4050631cf7f561b8ce648ac04d9b3c86a6972b2f5e3a84e4d6139a1@%3Cgeneral.incubator.apache.org%3E
(For some reason, Billie's vote shows up at
http://mail-archives.apache.org/mod_mbox/incubator-general/201707.mbox/%3CCAF1jEfCnmjL4epETXjVb_cmwFUndG79Rpg8y%2ByjN6VQVDt_j0A%40mail.gmail.com%3E
but
not in lists.apache.org)

On Thu, Jul 13, 2017 at 3:16 AM Pierre Smits  wrote:

> +1
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jul 12, 2017 at 8:45 PM, Dave Fisher 
> wrote:
>
> > +1 (binding)
> > > On Jul 10, 2017, at 1:44 PM, Christopher  wrote:
> > >
> > > Hello IPMC,
> > >
> > > The recent DISCUSS thread on the topic of Fluo's graduation has been
> open
> > > for at least 72 hours, and I believe all questions have been answered
> and
> > > issues addressed at this point.
> > >
> > > With the discussion having settled down, I would now like to call for a
> > > recommendation VOTE to present the ASF board with the following
> > resolution
> > > to graduate from incubation and establish Apache Fluo as a top-level
> > > project (TLP).
> > >
> > > Incubator DISCUSS thread:
> > > https://lists.apache.org/thread.html/214424f03d6f7b47f3abc1e3da7726
> > 27390a07960daa8b95365380bc@%3Cgeneral.incubator.apache.org%3E
> > > Fluo PPMC DISCUSS thread:
> > > https://lists.apache.org/thread.html/3164d77ea18c3e36ce215ab4a07b2c
> > b80cf9c49c2503ef5d1defbdde@%3Cdev.fluo.apache.org%3E
> > > Fluo PPMC internal VOTE thread:
> > > https://lists.apache.org/thread.html/04a9de260fcd14b184ae7a8b725e34
> > 8e13ee4ad10e3057a6a404732c@%3Cprivate.fluo.apache.org%3E
> > > Fluo Podling Status page: https://incubator.apache.org/projects/fluo
> > >
> > > Please vote on whether to recommend the following graduation resolution
> > to
> > > the ASF Board.
> > >
> > > [  ]  +1, In favor of recommending the following graduation resolution
> to
> > > the ASF Board to establish Apache Fluo as a TLP
> > > [  ]  +0, Neither opposed to, nor in favor of, recommending the
> following
> > > graduation resolution to the Board
> > > [  ]  -1, Opposed to recommending the following graduation resolution
> to
> > > the Board
> > >
> > > This VOTE will be open for at least 72 hours.
> > >
> > > ***Resolution:
> > >
> > > Establish the Apache Fluo Project
> > >
> > > WHEREAS, the Board of Directors deems it to be in the best interests of
> > > the Foundation and consistent with the Foundation's purpose to
> establish
> > > a Project Management Committee charged with the creation and
> maintenance
> > > of open-source software, for distribution at no charge to the public,
> > > related to the storage and incremental processing of large data sets.
> > >
> > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > (PMC), to be known as the "Apache Fluo Project", be and hereby is
> > > established pursuant to Bylaws of the Foundation; and be it further
> > >
> > > RESOLVED, that the Apache Fluo Project be and hereby is responsible for
> > > the creation and maintenance of software related to the storage and
> > > incremental processing of large data sets; and be it further
> > >
> > > RESOLVED, that the office of "Vice President, Apache Fluo" be and
> hereby
> > > is created, the person holding such office to serve at the direction of
> > > the Board of Directors as the chair of the Apache Fluo Project, and to
> > > have primary responsibility for management of the projects within the
> > > scope of responsibility of the Apache Fluo Project; and be it further
> > >
> > > RESOLVED, that the persons listed immediately below be and hereby are
> > > appointed to serve as the initial members of the Apache Fluo Project:
> > >
> > > * Billie Rinaldi 
> > > * Chris McTague 
> > > * Christopher Tubbs 
> > > * Corey J. Nolet 
> > > * Drew Farris 
> > > * Josh Elser 
> &g

INFRA guide to graduation?

[Christopher]

Is there any documentation detailing how to file a proper and complete JIRA
for graduation?
For example, which components should be put in the JIRA, issue type, etc.

It seems to me that good docs in this regard could save INFRA a lot of
headaches, and could help projects understand which infrastructure bits
they need to think about as they move from the Incubator infrastructure to
the TLP infrastructure.

Perhaps these exist already and I just haven't found them?

Re: INFRA guide to graduation?

[Christopher]

Unfortunately, the instructions there don't work. Creating "New TLP" issue
type won't work because required "Project" field is blank (but neither is
it presented so that it can be filled out). Creating "New TLP - Common
Tasks" is not an option when creating a sub-task, as instructed.

On Mon, Jul 24, 2017 at 8:12 PM John D. Ament  wrote:

> Christopher,
>
> Please review [
> <
> https://incubator.apache.org/guides/transferring.html#first_steps_outside_the_incubator
> >
> 1]
>
> If something seems off - we just did a review [2], please feel free to
> comment.  Or have infra knock on our door.
>
>
> John
>
> [1]:
>
> https://incubator.apache.org/guides/transferring.html#first_steps_outside_the_incubator
> [2]:
>
> https://lists.apache.org/thread.html/13ac64b765bf6810586dbfac283f18dc916f4c07e583a17d5ee5178c@%3Cgeneral.incubator.apache.org%3E
>
>
> On Mon, Jul 24, 2017 at 7:30 PM Christopher  wrote:
>
> > Is there any documentation detailing how to file a proper and complete
> JIRA
> > for graduation?
> > For example, which components should be put in the JIRA, issue type, etc.
> >
> > It seems to me that good docs in this regard could save INFRA a lot of
> > headaches, and could help projects understand which infrastructure bits
> > they need to think about as they move from the Incubator infrastructure
> to
> > the TLP infrastructure.
> >
> > Perhaps these exist already and I just haven't found them?
> >
>

Re: INFRA guide to graduation?

[Christopher]

Still a few issues with the process. I'm chatting on HipChat with INFRA now.
They pointed me to:
https://issues.apache.org/jira/servicedesk/customer/portal/1/group/12

But, there's still issues. I noted the following in HipChat:

"""
Yeah, I did that. However, common-tasks can't be set as a sub-task of the
parent, and "None" is not an acceptable value for the required Project
field, and the ticket names don't quite match the INFRA instructions at
http://www.apache.org/dev/infra-contact#requesting-graduation and it's not
clear what one should set as the component (I set "TLP Admin").
"""

It's minor stuff, but still a bit confusing. I'm sure we'll get it ironed
out.


On Wed, Jul 26, 2017 at 2:10 PM John D. Ament 
wrote:

> Looks like the link to
> https://issues.apache.org/jira/servicedesk/customer/portal/1/create/10 is
> missing.
>
> On Jul 26, 2017 1:53 PM, "Christopher"  wrote:
>
> > Unfortunately, the instructions there don't work. Creating "New TLP"
> issue
> > type won't work because required "Project" field is blank (but neither is
> > it presented so that it can be filled out). Creating "New TLP - Common
> > Tasks" is not an option when creating a sub-task, as instructed.
> >
> > On Mon, Jul 24, 2017 at 8:12 PM John D. Ament 
> > wrote:
> >
> > > Christopher,
> > >
> > > Please review [
> > > <
> > > https://incubator.apache.org/guides/transferring.html#
> > first_steps_outside_the_incubator
> > > >
> > > 1]
> > >
> > > If something seems off - we just did a review [2], please feel free to
> > > comment.  Or have infra knock on our door.
> > >
> > >
> > > John
> > >
> > > [1]:
> > >
> > > https://incubator.apache.org/guides/transferring.html#
> > first_steps_outside_the_incubator
> > > [2]:
> > >
> > > https://lists.apache.org/thread.html/13ac64b765bf6810586dbfac283f18
> > dc916f4c07e583a17d5ee5178c@%3Cgeneral.incubator.apache.org%3E
> > >
> > >
> > > On Mon, Jul 24, 2017 at 7:30 PM Christopher 
> wrote:
> > >
> > > > Is there any documentation detailing how to file a proper and
> complete
> > > JIRA
> > > > for graduation?
> > > > For example, which components should be put in the JIRA, issue type,
> > etc.
> > > >
> > > > It seems to me that good docs in this regard could save INFRA a lot
> of
> > > > headaches, and could help projects understand which infrastructure
> bits
> > > > they need to think about as they move from the Incubator
> infrastructure
> > > to
> > > > the TLP infrastructure.
> > > >
> > > > Perhaps these exist already and I just haven't found them?
> > > >
> > >
> >
>

Re: [DISCUSS] Podlings & Gitbox Usage

[Christopher]

+1

However, I would personally prefer to see all projects using git-wip
automatically migrated to GitBox, and have the old host(s) redirect to
gitbox, so the migration is completely transparent. It doesn't force any
projects to use GitBox features, but I can't see any downside, and it gives
everybody the option to use the GitBox features if they choose to, going
forward. (Migration to GitBox does not automatically enable GitHub issues
or other GitHub features. It only gives project members write access to
GitHub repos, and all that entails, and use of all of that is entirely
optional.)

If the conversion happened this way, it seems like it'd be easier for INFRA
to do in bulk, rather than convert projects one-by-one.

On Fri, Jul 28, 2017 at 11:48 AM John D. Ament 
wrote:

> All,
>
> As many are aware, Infra has been rolling out a new service that allows
> projects to leverage git repositories dually hosted on github and ASF git
> repositories, commonly known as gitbox.  This effectively allows a project
> to commit directly to Github and have those commits reflect back on the ASF
> side.
>
> This has been especially useful to a number of projects, since the github
> interface gives many options for managing repositories.  I've recently also
> asked infra to open it up to allow any IPMC member to request a gitbox
> repository for any approved podling that is using gitbox.  Podlings I think
> have found this useful, since many of them come from a github background.
> They like using the tool and having it available for all to use.
>
> So with that said, I want to propose some broad incubator wide policies for
> gitbox.  I'd like to propose that gitbox usage is approved for all
> podlings, there is nothing to inhibit a podling to request a gitbox
> repository and as long as a podling feels the need to use gitbox, like they
> would any other tool that we can integrate with, they should be free to use
> it without any additional approvals required.
>
> So please let me know your thoughts.  If I don't hear any -1's I plan to
> submit an infra ticket early next week to enable the access for all
> approved podlings.  Please note that your first conversion may need some
> lead time with infra.
>
> Regards,
>
> John
>

Re: [DISCUSS] Podlings & Gitbox Usage

[Christopher]

Understood. To be clear, I was merely stating a wish for how a migration
might work, because I think GitBox is great and would like to see as many
people have it as an option as possible. My wish is not a statement about
what infra currently is willing or capable of doing.

I'm sensitive to infra's support resource limitations, and the reason I
think this might be worth infra's serious consideration is because it seems
possible that a behind-the-scenes migration, like what I suggested, to the
superior GitBox service, might be easier to accomplish than infra handling
a large number of individual migration requests. If supporting the legacy
git-wip in addition to GitBox, as well as handling individual migration
requests, is a better use of resources, then so be it. I have no insight
into which is better. I suggest it only for consideration by those who have
more insight than me. :)

On Fri, Jul 28, 2017 at 5:45 PM Greg Stein  wrote:

> The service is not in general release, so no: we won't be mass-migrating
> projects, and we reserve the right to halt migration requests.
>
> On Jul 28, 2017 13:30, "Christopher"  wrote:
>
> > +1
> >
> > However, I would personally prefer to see all projects using git-wip
> > automatically migrated to GitBox, and have the old host(s) redirect to
> > gitbox, so the migration is completely transparent. It doesn't force any
> > projects to use GitBox features, but I can't see any downside, and it
> gives
> > everybody the option to use the GitBox features if they choose to, going
> > forward. (Migration to GitBox does not automatically enable GitHub issues
> > or other GitHub features. It only gives project members write access to
> > GitHub repos, and all that entails, and use of all of that is entirely
> > optional.)
> >
> > If the conversion happened this way, it seems like it'd be easier for
> INFRA
> > to do in bulk, rather than convert projects one-by-one.
> >
> > On Fri, Jul 28, 2017 at 11:48 AM John D. Ament 
> > wrote:
> >
> > > All,
> > >
> > > As many are aware, Infra has been rolling out a new service that allows
> > > projects to leverage git repositories dually hosted on github and ASF
> git
> > > repositories, commonly known as gitbox.  This effectively allows a
> > project
> > > to commit directly to Github and have those commits reflect back on the
> > ASF
> > > side.
> > >
> > > This has been especially useful to a number of projects, since the
> github
> > > interface gives many options for managing repositories.  I've recently
> > also
> > > asked infra to open it up to allow any IPMC member to request a gitbox
> > > repository for any approved podling that is using gitbox.  Podlings I
> > think
> > > have found this useful, since many of them come from a github
> background.
> > > They like using the tool and having it available for all to use.
> > >
> > > So with that said, I want to propose some broad incubator wide policies
> > for
> > > gitbox.  I'd like to propose that gitbox usage is approved for all
> > > podlings, there is nothing to inhibit a podling to request a gitbox
> > > repository and as long as a podling feels the need to use gitbox, like
> > they
> > > would any other tool that we can integrate with, they should be free to
> > use
> > > it without any additional approvals required.
> > >
> > > So please let me know your thoughts.  If I don't hear any -1's I plan
> to
> > > submit an infra ticket early next week to enable the access for all
> > > approved podlings.  Please note that your first conversion may need
> some
> > > lead time with infra.
> > >
> > > Regards,
> > >
> > > John
> > >
> >
>

Removing Fluo from podling reporting schedule

[Christopher]

It seems Fluo is on the podling reporting schedule for August, but since
we've just graduated, we're not sure if we need to submit a final report,
or just focus on our own first TLP report.
Any guidance here?


On Tue, Aug 1, 2017 at 3:47 AM  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 16 August 2017, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, August 02).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/August2017
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: Removing Fluo from podling reporting schedule

[Christopher]

For now, I guess we're assuming we only need to file our TLP board report,
and are currently disregarding the podling report reminders, unless we
receive guidance saying otherwise. But, I'm still hoping that somebody will
positively confirm whether we're doing the right thing and/or explain how
to remove us from the podling reporting schedule. Thanks.

On Tue, Aug 1, 2017 at 5:14 PM Christopher  wrote:

> It seems Fluo is on the podling reporting schedule for August, but since
> we've just graduated, we're not sure if we need to submit a final report,
> or just focus on our own first TLP report.
> Any guidance here?
>
>
> On Tue, Aug 1, 2017 at 3:47 AM  wrote:
>
>> Dear podling,
>>
>> This email was sent by an automated system on behalf of the Apache
>> Incubator PMC. It is an initial reminder to give you plenty of time to
>> prepare your quarterly board report.
>>
>> The board meeting is scheduled for Wed, 16 August 2017, 10:30 am PDT.
>> The report for your podling will form a part of the Incubator PMC
>> report. The Incubator PMC requires your report to be submitted 2 weeks
>> before the board meeting, to allow sufficient time for review and
>> submission (Wed, August 02).
>>
>> Please submit your report with sufficient time to allow the Incubator
>> PMC, and subsequently board members to review and digest. Again, the
>> very latest you should submit your report is 2 weeks prior to the board
>> meeting.
>>
>> Thanks,
>>
>> The Apache Incubator PMC
>>
>> Submitting your Report
>>
>> --
>>
>> Your report should contain the following:
>>
>> *   Your project name
>> *   A brief description of your project, which assumes no knowledge of
>> the project or necessarily of its field
>> *   A list of the three most important issues to address in the move
>> towards graduation.
>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>> aware of
>> *   How has the community developed since the last report
>> *   How has the project developed since the last report.
>> *   How does the podling rate their own maturity.
>>
>> This should be appended to the Incubator Wiki page at:
>>
>> https://wiki.apache.org/incubator/August2017
>>
>> Note: This is manually populated. You may need to wait a little before
>> this page is created from a template.
>>
>> Mentors
>> ---
>>
>> Mentors should review reports for their project(s) and sign them off on
>> the Incubator wiki page. Signing off reports shows that you are
>> following the project - projects that are not signed may raise alarms
>> for the Incubator PMC.
>>
>> Incubator PMC
>>
>

Re: Removing Fluo from podling reporting schedule

[Christopher]

Ah, thanks John!

On Wed, Aug 2, 2017 at 7:39 PM John D. Ament  wrote:

> I removed Fluo from the reporting schedule yesterday.
>
> John
>
> On Wed, Aug 2, 2017 at 3:01 PM Dave Fisher  wrote:
>
> > Hi -
> >
> > I am not sure how to modify the podling report reminders. I think you
> will
> > need to wait for John.
> >
> > The Board accepted your resolution. You are a TLP and the Incubator no
> > longer needs your report.
> >
> > Regards,
> > Dave
> >
> > > On Aug 2, 2017, at 11:49 AM, Christopher  wrote:
> > >
> > > For now, I guess we're assuming we only need to file our TLP board
> > report,
> > > and are currently disregarding the podling report reminders, unless we
> > > receive guidance saying otherwise. But, I'm still hoping that somebody
> > will
> > > positively confirm whether we're doing the right thing and/or explain
> how
> > > to remove us from the podling reporting schedule. Thanks.
> > >
> > > On Tue, Aug 1, 2017 at 5:14 PM Christopher 
> wrote:
> > >
> > >> It seems Fluo is on the podling reporting schedule for August, but
> since
> > >> we've just graduated, we're not sure if we need to submit a final
> > report,
> > >> or just focus on our own first TLP report.
> > >> Any guidance here?
> > >>
> > >>
> > >> On Tue, Aug 1, 2017 at 3:47 AM  wrote:
> > >>
> > >>> Dear podling,
> > >>>
> > >>> This email was sent by an automated system on behalf of the Apache
> > >>> Incubator PMC. It is an initial reminder to give you plenty of time
> to
> > >>> prepare your quarterly board report.
> > >>>
> > >>> The board meeting is scheduled for Wed, 16 August 2017, 10:30 am PDT.
> > >>> The report for your podling will form a part of the Incubator PMC
> > >>> report. The Incubator PMC requires your report to be submitted 2
> weeks
> > >>> before the board meeting, to allow sufficient time for review and
> > >>> submission (Wed, August 02).
> > >>>
> > >>> Please submit your report with sufficient time to allow the Incubator
> > >>> PMC, and subsequently board members to review and digest. Again, the
> > >>> very latest you should submit your report is 2 weeks prior to the
> board
> > >>> meeting.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> The Apache Incubator PMC
> > >>>
> > >>> Submitting your Report
> > >>>
> > >>> --
> > >>>
> > >>> Your report should contain the following:
> > >>>
> > >>> *   Your project name
> > >>> *   A brief description of your project, which assumes no knowledge
> of
> > >>>the project or necessarily of its field
> > >>> *   A list of the three most important issues to address in the move
> > >>>towards graduation.
> > >>> *   Any issues that the Incubator PMC or ASF Board might wish/need to
> > be
> > >>>aware of
> > >>> *   How has the community developed since the last report
> > >>> *   How has the project developed since the last report.
> > >>> *   How does the podling rate their own maturity.
> > >>>
> > >>> This should be appended to the Incubator Wiki page at:
> > >>>
> > >>> https://wiki.apache.org/incubator/August2017
> > >>>
> > >>> Note: This is manually populated. You may need to wait a little
> before
> > >>> this page is created from a template.
> > >>>
> > >>> Mentors
> > >>> ---
> > >>>
> > >>> Mentors should review reports for their project(s) and sign them off
> on
> > >>> the Incubator wiki page. Signing off reports shows that you are
> > >>> following the project - projects that are not signed may raise alarms
> > >>> for the Incubator PMC.
> > >>>
> > >>> Incubator PMC
> > >>>
> > >>
> >
> >
>

Re: Digests in releases

[Christopher]

On Wed, Aug 30, 2017 at 5:08 PM Julian Hyde  wrote:

> What is the correct forum for discussing release distribution policy?
>
>
Good question. I hope it's this one, since this is where the discussion is
happening.



> Current policy [1] states:
>
>   Every artifact distributed to the public through Apache channels MUST
>   be accompanied by one file containing an OpenPGP compatible ASCII
>   armored detached signature and another file containing an MD5 checksum.
>
>   ...
>
>   An SHA checksum SHOULD also be created.
>
>
> MD5 is no longer deemed secure[2]. I think we should remove it from
> our releases and mandate SHA256 or SHA512.
>
>

A good policy is simple and flexible, in my opinion. Rather than require
any specific checksum with others optional, I would personally like to see
the policy changed to simply require "a detached ASCII-armored GPG
signature named .asc for each  release artifact, and one or
more standard checksums with a minimum strength of MD5 in a standard file
format with a convenient file naming convention"

Such a policy could easily be updated by simply changing the "minimum
strength", if necessary, in the future. But changing the policy to allow
PMCs to drop support for legacy hashes, replaced by newer standards, is
infinitely better, in my opinion.

If my wording needs clarification:

  By "standard checksums", I mean MD5, SHA1, or any of the SHA2 family
currently, but maybe SHA3 family in future.
  By "standard file format", I mean a plain text file containing only the
ASCII encoded hex representation of the hash or in a format such as those
output by the 'sha*sum' suite of tools (example:
https://www.systutorials.com/docs/linux/man/1-sha512sum/).
  By "convenient file naming convention", I mean the artifact file name
with an appended ".md5 or .sha\d*" or aggregated into a file such as
CHECKSUMS, SHA1SUM, MD5SUM, etc. for the convenience of verifying multiple
artifact files from a release.

Modifying the policy in this way, we can eliminate requirements for legacy
hashes and inconvenient (as determined by PMCs for their users, not by
INFRA) file naming conventions. Of course, the file naming conventions
would still have to fit into constraints imposed by INFRA for the mirroring
system, or Maven deployments, or whatever, but these would simply be
implementation details, rather than enshrined in policy (which I think is
better, because policy should be simple and shouldn't change as much; INFRA
should be able to update implementation details, upon request, to allow
more conventions as new projects come on board with their own conventions,
and as verification tools and de facto standards around the internet
evolve).



> Julian
>
> [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums
>
> [2] https://en.wikipedia.org/wiki/Md5sum
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Digests in releases

[Christopher]

My proposal was an attempt to achieve two goals:

1. Drop the absolute MD5 requirement in favor of an "at least MD5"
requirement, and
2. Make [2] consistent with [3] by dropping file naming conventions in [2],
and deferring to the constraints in [3].

If my existing wording is too complex, I'm sure it could be rewritten to
achieve both of these goals with simpler wording. If considering both goals
at the same time is too much to address at once, we could just focus on #1,
since that's more relevant to the topic this thread started with.

On Sat, Sep 2, 2017 at 6:00 AM Henk P. Penning  wrote:

> On Fri, 1 Sep 2017, Christopher wrote:
>
> > Date: Fri, 1 Sep 2017 03:29:58 +0200
> > From: Christopher 
> > To: general@incubator.apache.org
> > Subject: Re: Digests in releases
> >
> > On Wed, Aug 30, 2017 at 5:08 PM Julian Hyde  wrote:
> >
> >> What is the correct forum for discussing release distribution policy?
> >>
> >>
> > Good question. I hope it's this one, since this is where the discussion
> is
> > happening.
> >
> >
> >
> >> Current policy [1] states:
> >>
> >>   Every artifact distributed to the public through Apache channels MUST
> >>   be accompanied by one file containing an OpenPGP compatible ASCII
> >>   armored detached signature and another file containing an MD5
> checksum.
> >>
> >>   ...
> >>
> >>   An SHA checksum SHOULD also be created.
> >>
> >>
> >> MD5 is no longer deemed secure[2]. I think we should remove it from
> >> our releases and mandate SHA256 or SHA512.
>
> >> [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums
> >> [2] https://en.wikipedia.org/wiki/Md5sum
>
> >
> > A good policy is simple and flexible, in my opinion. Rather than require
> > any specific checksum with others optional, I would personally like to
> see
> > the policy changed to simply require "a detached ASCII-armored GPG
> > signature named .asc for each  release artifact, and one or
> > more standard checksums with a minimum strength of MD5 in a standard file
> > format with a convenient file naming convention"
> >
> > Such a policy could easily be updated by simply changing the "minimum
> > strength", if necessary, in the future. But changing the policy to allow
> > PMCs to drop support for legacy hashes, replaced by newer standards, is
> > infinitely better, in my opinion.
>
>The '(legal) release policy' [1] says /what/ we want, and /why/.
>-- note that [1] doesn't even mention checksums.
>The 'Release Distribution Policy' [2] says /how/ we do it.
>-- because [2] is about 'implementation' it should preferably be :
>   -- simple, strict, unambiguous and short
>   -- easy to explain and easy to understand
>   -- ASF-wide
>
>I think the current scheme has the prefered properties.
>
>[1] http://www.apache.org/legal/release-policy.html
>[2] http://www.apache.org/dev/release-distribution
>[3] http://www.apache.org/dev/release-publishing
>
> > If my wording needs clarification:
> >
> >  By "standard checksums", I mean MD5, SHA1, or any of the SHA2 family
> > currently, but maybe SHA3 family in future.
> >  By "standard file format", I mean a plain text file containing only the
> > ASCII encoded hex representation of the hash or in a format such as those
> > output by the 'sha*sum' suite of tools (example:
> > https://www.systutorials.com/docs/linux/man/1-sha512sum/).
> >  By "convenient file naming convention", I mean the artifact file name
> > with an appended ".md5 or .sha\d*" or aggregated into a file such as
> > CHECKSUMS, SHA1SUM, MD5SUM, etc. for the convenience of verifying
> multiple
> > artifact files from a release.
>
>If I understand you correctly, the operational word here is "or"
>in "or aggregated into a file [...]".
>
>-- The scheme you propose is more complex than the current scheme ;
>   therefor, a priori, it isn't better.
>-- In your scheme, the checksum of a given file can be in multiple
>   places ; this error-prone, harder to use, check and report.
>-- Note that [3] /allows/ you to supply 'MD5SUM' and 'SHA*SUM' files,
>   but [3] also says that in general checksum files shouldn't leak
>   to the mirrors, so a list of excluded files is provided ;
>   a short list is better than a long list.
>   [the l

Update README for retired podlings?

[Christopher]

Should the Apache Incubator update the README on all retired podlings, to
more clearly indicate their retired status?

For example, from the README at https://github.com/apache/incubator-pirk ,
it's not obvious that the podling is retired.

I know there's a RETIRED.txt file, but that's easily overlooked. I suggest
the Incubator PMC updating the retired projects' README's with an
indication that the podling is retired, perhaps with a link to an
explanation of what that means:
https://incubator.apache.org/guides/retirement.html#what_is_retirement

For example, simply inserting the following line at the top of retired
podlings README's may suffice:

This project is [retired](
https://incubator.apache.org/guides/retirement.html#what_is_retirement)

I don't think this is a big deal, but might be something nice to do.
Another option is to stop mirroring retired podlings to GitHub, but that
just seems mean.

Re: Update README for retired podlings?

[Christopher]

I just meant "mean" in that it makes it harder for the project to be picked
back up if there's renewed interest. I understand deleting SVN... because
it's still in the history, but I think it's strange if ASF deleted GIT...
because that deletes history. Perhaps just delete the GIT mirror on GitHub?

On Thu, Nov 2, 2017 at 5:07 PM Dave Fisher  wrote:

> Actually when the podling is retired the SVN and or GIT must be deleted.
> It’s mean, but if people cared they could have contributed and kept it
> going.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Nov 2, 2017, at 1:56 PM, Christopher  wrote:
> >
> > Should the Apache Incubator update the README on all retired podlings, to
> > more clearly indicate their retired status?
> >
> > For example, from the README at https://github.com/apache/incubator-pirk
> ,
> > it's not obvious that the podling is retired.
> >
> > I know there's a RETIRED.txt file, but that's easily overlooked. I
> suggest
> > the Incubator PMC updating the retired projects' README's with an
> > indication that the podling is retired, perhaps with a link to an
> > explanation of what that means:
> > https://incubator.apache.org/guides/retirement.html#what_is_retirement
> >
> > For example, simply inserting the following line at the top of retired
> > podlings README's may suffice:
> >
> >This project is [retired](
> > https://incubator.apache.org/guides/retirement.html#what_is_retirement)
> >
> > I don't think this is a big deal, but might be something nice to do.
> > Another option is to stop mirroring retired podlings to GitHub, but that
> > just seems mean.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Question about IP CLEARANCE

[Christopher]

Two questions about IP CLEARANCE:

There is a line item in the template for making sure that files are updated
to reflect ASF copyright. Must this be done before the files are actually
transferred to the receiving PMC, while still being hosted in the donating
party's repository? It seems to me that this could be done after transfer,
but before any release by the PMC, and it would be inappropriate to do this
before IP CLEARANCE has been approved, while the code is still sitting in
the donating party's repo. (Note: we're not donating a patch... otherwise
the patch would include any such alterations; rather, we're trying to
donate an entire git repo from one GitHub organization to an ASF project).

There is an item that says to remind active committers that they are
responsible for ensuring that a CCLA is recorded if required to authorize
their contributions under their ICLA. All the contributors to the incoming
codebase already have ICLAs on file because they are already committers to
ASF projects. Since CLAs are already filed, is this reminder necessary?
Presumably, by filing an ICLA, these committers have already accepted that
responsibility. It doesn't seem to have anything to do with this donation,
though. Does it make sense to remind people to do X before Y, when Y is a
NOOP for them?

Thanks,

Christopher

Re: Question about IP CLEARANCE

[Christopher]

On Mon, Apr 16, 2018 at 8:28 PM Roman Shaposhnik 
wrote:

> On Mon, Apr 16, 2018 at 4:18 PM, Christopher  wrote:
> > Two questions about IP CLEARANCE:
> >
> > There is a line item in the template for making sure that files are
> updated
> > to reflect ASF copyright. Must this be done before the files are actually
> > transferred to the receiving PMC, while still being hosted in the
> donating
> > party's repository?
>
> There's no requirement like that. You can transfer files into a branch and
> do the clean up on ASF infrastructure. You will NOT be able to do releases
> off of that branch, of course.
>
>
It's pretty clearly documented:
http://incubator.apache.org/ip-clearance/ip-clearance-template.html
If it's not a requirement, why is it there? Can I just delete it from the
template?

Re: Question about IP CLEARANCE

[Christopher]

On Mon, Apr 16, 2018 at 10:34 PM Dave Fisher  wrote:

>
>
> Sent from my iPhone
>
> > On Apr 16, 2018, at 7:16 PM, Christopher  wrote:
> >
> > On Mon, Apr 16, 2018 at 8:28 PM Roman Shaposhnik 
> > wrote:
> >
> >>> On Mon, Apr 16, 2018 at 4:18 PM, Christopher 
> wrote:
> >>> Two questions about IP CLEARANCE:
> >>>
> >>> There is a line item in the template for making sure that files are
> >> updated
> >>> to reflect ASF copyright. Must this be done before the files are
> actually
> >>> transferred to the receiving PMC, while still being hosted in the
> >> donating
> >>> party's repository?
> >>
> >> There's no requirement like that. You can transfer files into a branch
> and
> >> do the clean up on ASF infrastructure. You will NOT be able to do
> releases
> >> off of that branch, of course.
> >>
> >>
> > It's pretty clearly documented:
> > http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> > If it's not a requirement, why is it there? Can I just delete it from the
> > template?
>
> No, I’m not reading the page the same way that you are. To be clear the
> two lines about SGA/CCLA and Copyright changes are separate, not
> simultaneous.
>
> Here are the real steps.
>
> (1) Submit SGA/CCLA to secretary@
> (2) Do IP Clearance with Incubator.
> (3) Arrange with Infra and/or project moving / checking in the code.
> (4) Update Copyrights - if needed. Always best if it’s someone from the
> contributor.
>
>
That list appears to be self referential:

Steps for IP Clearancce:
1. do ...
2. do "Steps for IP Clearance"
3. do ...

That is very confusing.


> If you want to suggest updating the language or the recording tables then
> please provide it for discussion.
>
>
I like to try to understand a process before suggesting changes to it. I
can try to start making some suggestions now to change
http://incubator.apache.org/ip-clearance/ip-clearance-template.html  and
http://incubator.apache.org/ip-clearance/ ; what is the best delivery
method for suggesting changes? Can I attach a patch to this list or does
the Incubator website have an issue tracker I should use? (Related thought:
this would be easier if incubator website was git-based on gitbox; I could
just do a pull request 😺)

Re: Review mailing list membership?

[Christopher]

Have you tried the tool at
https://whimsy.apache.org/committers/moderationhelper.cgi ?

On Tue, Apr 17, 2018 at 2:06 PM Gian Merlino  wrote:

> Hi incubators,
>
> Is there a tool somewhere to review the membership of a mailing list?
>
> We (Druid) are working on migrating our mailing lists now. As I work out
> the logistics of doing that I am finding that it would help to know how
> many people from the old list have subscribed to the new one, as we have
> been encouraging people to do for about a month. If the overlap is good
> then we know we are clear to migrate without leaving too many people
> behind. If the overlap is poor then we know we need to do more outreach to
> get people to subscribe to the new list.
>
> Gian
>

[IP CLEARANCE] Fluo contributions from Astralway

[Christopher]

The Apache Fluo PMC has voted[1] to receive a large contribution from the
"Astralway" team on GitHub. The IP Clearance page has been updated[2],
though recent SVN updates to the xml[3] may not be reflected yet.

The clearance passes by lazy consensus if no -1 votes are cast within the
next 72 hours.

Thanks,

Christopher Tubbs

[1]:
https://lists.apache.org/thread.html/921012ad4be72642e81e1f06aee1bdb6c973e85f76f91bc12c180a84@%3Cdev.fluo.apache.org%3E
[2]:
https://incubator.apache.org/ip-clearance/fluo-astralway-code-repos.html
[3]:
https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/fluo-astralway-code-repos.xml

[RESULT][IP CLEARANCE] Fluo contributions from Astralway

[Christopher]

IP Clearance passes by lazy consensus.

On Mon, Apr 23, 2018 at 6:08 PM Christopher  wrote:

> The Apache Fluo PMC has voted[1] to receive a large contribution from the
> "Astralway" team on GitHub. The IP Clearance page has been updated[2],
> though recent SVN updates to the xml[3] may not be reflected yet.
>
> The clearance passes by lazy consensus if no -1 votes are cast within the
> next 72 hours.
>
> Thanks,
>
> Christopher Tubbs
>
> [1]:
> https://lists.apache.org/thread.html/921012ad4be72642e81e1f06aee1bdb6c973e85f76f91bc12c180a84@%3Cdev.fluo.apache.org%3E
> [2]:
> https://incubator.apache.org/ip-clearance/fluo-astralway-code-repos.html
> [3]:
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/fluo-astralway-code-repos.xml
>
>

Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)

[Christopher]

On Wed, May 23, 2018 at 12:16 AM Greg Stein  wrote:

> On Mon, May 21, 2018 at 2:52 AM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > > Javascript code that is minified or combined in any major way is much
> > more
> > > like binary code in that respect. It is true that somebody *could*
> > inspect
> > > the correlation, but it is not true that this inspection is either
> > normally
> > > done or easily done.
> >
> > Thanks Ted I’ve not thought of it in that way before. I've seen several
> > source releases that include minified javascript I'm just curious what
> > people think about this.
> >
> > Do people think it OK to include minified JS in a source release if:
> > 1. It's ASF developed code and the full unminified source code is
> included
> > as well.
> >
>
> Absolutely.
>
>
Also agree, yes.


> Think "autoconf" ... the resulting "configure" file is as opaque as a
> minified JS file or a binary. Nobody edits/modifies that shell script. And
> we've been doing this for *years* ... it's natural and normal.
>
>
I agree. It's only a problem if the project does not include the original
source, like in https://issues.apache.org/jira/browse/THRIFT-4119 (an
outstanding omission of source issue currently described as "intended
behavior").


> The general rule is "don't place generated artifacts into source control",
> but we nearly always include generated artifacts in our source releases.
>
>
> > 2. The minified JS is 3rd party code, is identified by version (and thus
> > can be checked via a comparison with the canonical minified version)
> >
>
> I recommend using a CDN for these, when possible (eg. bootstrap and jquery)
> as noted else-thread. That works well for the end-user, and avoids many of
> these questions.
>
>
Accumulo recently addressed a similar situation. We ended up bundling
non-minimized, but made the webapp configurable, in case users want to
switch to a non-bundled minimized version, a more up-to-date version
(jQuery gets a lot of security updates), or one from their preferred CDN. I
would strongly agree with Greg's recommendation to use a CDN by default...
but if you need to bundle... making it user-configurable might be an option.

There might be another good reason to avoid bundling minified versions, and
this reason specifically applies to *minified* (obfuscated) source (rather
than to all generated code): that is, it's not considered "free software"
according to the Free Software Foundation (
http://www.gnu.org/philosophy/free-sw.html), nor are they considered "open
source" according to the Open Source Initiative (http://opensource.org/osd).
Of course, these definitions aren't necessarily ASF definitions... but they
do tend to be respected definitions (this was first brought to my attention
by the Fedora/RedHat community, which tends to be very strict about these
things).


> Cheers,
> -g
>

Re: Turn on GitHub Issues on apache/incubator

[Christopher]

Ideally, the GitHub traffic would go to a separate list... yes?

On Thu, Jun 3, 2021 at 12:42 PM Julian Hyde  wrote:
>
> How much will this increase the email traffic?
>
> > On Jun 3, 2021, at 9:39 AM, Dave Fisher  wrote:
> >
> > Unless there is an objection I will turn on GitHub Issues on 
> > https://github.com/apache/incubator next Monday.
> >
> > I’ll also set notifications so that PRs and issues are sent to general@i.a.o
> >
> > See 
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
> >
> > This will make it easier to track observations like sebb’s on the 
> > retirement page.
> >
> > Regards,
> > Dave
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: eliminating MD5 and SHA1 signatures

[Christopher]

No. These are generated as part of Maven, and are described as part of
the Maven2 repository layout[1]. They are (optionally) used by the
artifact resolver in the Maven client to validate artifacts when they
are retrieved from a server using the Maven2 repository layout.

It's possible that the tooling will change over time to use newer
hashes... but I would just ignore these, accepting them as part of the
Maven tooling, and not necessary to interact with directly.

[1]: 
https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final

On Fri, Jan 17, 2020 at 3:51 PM leerho  wrote:
>
> When I deploy to repository.apache.org
>  in addition to the .asc
> signatures, either the Maven deploy plugin or the repository always adds
> MD5 and SHA1 signatures as well.
>
> Is there a configuration somewhere that will eliminate these being added?
>
> Lee.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Zipkin incubator status needs updating

[Christopher]

I noticed a broken Jenkins job for Zipkin on builds.apache.org
But, when I checked into it further, I saw:

https://github.com/apache/zipkin redirects outside of Apache.
https://zipkin.apache.org doesn't exist

According to https://whimsy.apache.org/roster/ppmc/zipkin , I think it
is retired, but the incubation status page is not up-to-date with that
information: https://incubator.apache.org/projects/zipkin.html , and I
can only see the Whimsy information because I have a login to Whimsy.

If Zipkin is retired, can one of the former mentors please update the
public status page?

In the meantime, I'll proceed to delete the now defunct Jenkins job.

Thanks,
Christopher

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[PATCH][Agila] Fix typo in project.xml

[Christopher Lim]

Corrected an email typo.

Deleted  as it is deprecated.



Chris
Index: project.xml
===
--- project.xml (revision 57139)
+++ project.xml (working copy)
@@ -121,10 +121,9 @@
   
 
   
-[EMAIL PROTECTED]
+[EMAIL PROTECTED]
 src/java
 src/test
-
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH][Agila] Bug fix for instance data persistence

[Christopher Lim]

Added InstanceService in NodeContextImpl ctor and used it in saving
instance data instead of having a local variable "instanceData".

This bug is not obvious when using in-memory persistence.


Chris
Index: src/test/org/apache/agila/impl/NodeContextImplTestCase.java
===
--- src/test/org/apache/agila/impl/NodeContextImplTestCase.java (revision 57115)
+++ src/test/org/apache/agila/impl/NodeContextImplTestCase.java (working copy)
@@ -19,11 +19,13 @@
 
 import junit.framework.TestCase;
 import org.apache.agila.services.TimerService;
+import org.apache.agila.services.InstanceService;
 import org.apache.agila.services.notification.NotificationService;
 import org.apache.agila.services.task.TaskService;
 import org.apache.agila.impl.memory.TimerServiceImpl;
 import org.apache.agila.impl.memory.TaskServiceImpl;
 import org.apache.agila.impl.memory.NotificationServiceImpl;
+import org.apache.agila.impl.memory.InstanceServiceImpl;
 import org.apache.agila.model.node.HelloWorldActivity;
 import org.apache.agila.model.Binding;
 import org.apache.agila.model.Node;
@@ -105,6 +107,7 @@
 TimerService ts = new TimerServiceImpl();
 TaskService tskServ = new TaskServiceImpl();
 NotificationService notifyService = new NotificationServiceImpl();
+InstanceService instanceService = new InstanceServiceImpl();
 
 node = new HelloWorldActivity();
 
@@ -112,7 +115,7 @@
 
 node.addBinding(new Binding("drink", "drink", Binding.EL, true, true));
 
-context = new NodeContextImpl(node, new InstanceImpl(), ts, tskServ, 
notifyService );
+context = new NodeContextImpl(node, instanceService, new 
InstanceImpl(), ts, tskServ, notifyService );
 }
 
 protected void tearDown() throws Exception {
Index: src/java/org/apache/agila/impl/NodeContextImpl.java
===
--- src/java/org/apache/agila/impl/NodeContextImpl.java (revision 57115)
+++ src/java/org/apache/agila/impl/NodeContextImpl.java (working copy)
@@ -21,17 +21,16 @@
 import org.apache.agila.model.Binding;
 import org.apache.agila.model.Node;
 import org.apache.agila.model.NodeContext;
+import org.apache.agila.services.TimerService;
 import org.apache.agila.services.InstanceService;
 import org.apache.agila.services.notification.NotificationService;
 import org.apache.agila.services.task.TaskService;
-import org.apache.agila.services.TimerService;
 import org.apache.commons.jexl.Expression;
 import org.apache.commons.jexl.ExpressionFactory;
 import org.apache.commons.jexl.JexlContext;
 import org.apache.commons.jexl.JexlHelper;
 
 import java.util.HashMap;
-import java.util.Iterator;
 import java.util.Map;
 
 /**
@@ -43,19 +42,21 @@
 
 protected Token currentToken = null;
 protected Token nextToken = null;
+private InstanceService instanceService;
+private Instance instance;
 private TimerService ts = null;
 private TaskService taskService = null;
 private NotificationService notificationService = null;
 private Node node = null;
-private final Map instanceData;
 private Map appData = new HashMap();
 
-public NodeContextImpl(Node node, Instance instance,
-   TimerService timer, TaskService task,
-NotificationService notificationService) {
+public NodeContextImpl( Node node, InstanceService instanceService, 
Instance instance,
+TimerService timer, TaskService task,
+NotificationService notificationService ) {
 
 this.node = node;
-this.instanceData = instance.getInstanceVariables();
+this.instanceService = instanceService;
+this.instance = instance;
 this.ts = timer;
 this.taskService = task;
 this.notificationService = notificationService;
@@ -117,6 +118,7 @@
  */
 
 this.getInstanceData().put(binding.getName(), value);
+instanceService.save( instance );
 }
 catch(Exception e) {
 // TODO somethig useful
@@ -178,7 +180,7 @@
 this.appData = m;
 }
 public Map getInstanceData() {
-return instanceData;
+return instance.getInstanceVariables();
 }
 
 protected Object jexlResolver(String expression, Map vars)
Index: src/java/org/apache/agila/services/task/AbstractTaskService.java
===
--- src/java/org/apache/agila/services/task/AbstractTaskService.java
(revision 57115)
+++ src/java/org/apache/agila/services/task/AbstractTaskService.java
(working copy)
@@ -130,7 +130,7 @@
 Node node = getNodeForToken(token);
 
 NodeContextImpl ctx = new NodeContextImpl(node,
-instanceService.getInstanceByID(token.getInstanceID()),
+instanceService, 
ins

Re: Agila docs

[Christopher Lim]

coming soon.


On Mon, 20 Dec 2004 22:06:54 -0800 (PST), Hemali Kunjeer
<[EMAIL PROTECTED]> wrote:
> Hello,
> Where i can get agila documents for reference?
> 
> 
> -
> Do you Yahoo!?
>  Meet the all-new My Yahoo! â Try it today!
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Agila

[Christopher Lim]

Hi Kumaran,

First step is to subscribe on the following mailing lists:
[EMAIL PROTECTED]
[EMAIL PROTECTED]

We'll discuss Agila there.

Source is available at:
http://svn.apache.org/repos/asf/incubator/agila/trunk/

Cheers!

--
Chris


On Thu, 13 Jan 2005 18:36:46 -0700, kumx thum <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I am new to incubator mailing list. I am interested in participating
> in agila project. If anyone guide to me how to work with this
> community, it would be greatful.
> 
> Thanks,
> Kumaran.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Wave into the incubator

[Christopher Brind]

+1 (non-binding)

On 30 November 2010 06:52, Dan Peterson  wrote:

> Hi everyone,
>
> Please vote on the acceptance of Wave into the Apache incubator.
>
> The proposal is available at:
> http://wiki.apache.org/incubator/WaveProposal
> (for your convenience, a snapshot is also copied below)
>
> The earlier discussion thread can be found at:
>
> http://apache.markmail.org/message/3ebtccdxvipp2732?q=general%40incubator.apache.org+list:org.apache.incubator.general+order:date-backward&page=2
>
> The vote options:
>
> [ ] +1 Accept Wave for incubation
> [ ] +0 Don't care
> [ ] -1 Reject for the following reason:
>
> The vote is open for 72 hours.
>
> Thanks,
> -Dan
>
> Apache Wave Proposal (Apache Incubator)
>
> = Abstract =
>
> Apache Wave is the project where wave technology is developed at Apache.
> Wave in a Box (WIAB) is the name of the main product at the moment, which
> is
> a server that hosts and federates waves, supports extensive APIs, and
> provides a rich web client. This project also includes an implementation of
> the Wave Federation protocol, to enable federated collaboration systems
> (such as multiple interoperable Wave In a Box instances).
>
> = Proposal =
>
> A wave is a hosted, live, concurrent data structure for rich communication.
> It can be used like email, chat, or a document.
>
> WIAB is a server that hosts waves. The best analogy for this is a mail
> server with a web client. WIAB is comprised of a few high-level components:
> the client and the server. They have the following major functionality
> (though this is not an exhaustive list):
>
>  * Client
>  *A dynamic web client for users to create, edit, and search waves. Users
> can access this client by directly visiting the server in a browser.
>  * Gadgets provide the ability to insert, view, and modify the UI --
> exposing the Wave Gadgets API (
> http://code.google.com/apis/wave/extensions/gadgets/guide.html)
>  * A console client that can create and edit waves via a command-line-like
> interface.
>  * Server
>  * Hosts and stores waves. WIAB comes with a default storage mechanism. The
> administrators of the server may configure it to use alternative storage
> mechanisms.
>  * Indexing, allowing for searching the waves a user has access to.
>  * Basic authentication, configurable to delegate to other systems.
>  * Federation, allowing separate Wave in a Box servers to communicate with
> each other using the Wave Federation Protocol (
> http://www.waveprotocol.org/federation).
>  * Robots, using the Wave Robots API, (
> http://code.google.com/apis/wave/extensions/robots/) may interact with
> waves
> on a WIAB instance.
>
> = Background =
>
> Wave expresses a new metaphor for communication: hosted conversations. This
> was created by Lars and Jens Rasmussen after observation of people's use of
> many separate forms of communication to get something done, e.g, email,
> chat, docs, blogs, twitter, etc.
>
> The vision has always been to better the way people communicate and
> collaborate. Building open protocols and sharing code available in an open
> and free way is a critical part of that vision. Anyone should be able to
> bring up their own wave server and communicate with others (much like
> SMTP).
>
> We hope this project will allow everyone to easily gain the benefits of
> Wave
> with a standard implementation of Wave – in a box.
>
> = Rationale =
>
> Wave has shown it excels at small group collaboration when hosted by
> Google.
> Although Wave will not continue as a standalone Google product, there is a
> lot of interest from many organizations in both running Wave and building
> upon the technology for new products.
>
> We are confident that with the community-centric development environment
> fostered by the Apache Software Foundation, WIAB will thrive.
>
> = Initial Goals =
>
> The initial goals of the project are:
>
>  1.  To migrate the codebase from code.google.com and integrate the
> project
> with the ASF infrastructure (issue management, build, project site, etc).
>  1.  To quickly reach a state where it is possible to continue the
> development of the Wave In a Box implementation under the ASF project.
>  1.  To add new committers to the project and grow the community in "The
> Apache Way".
>
> = Current Status =
>
> The open source Wave in a Box project has existed in various forms for
> approximately 16 months (starting out life as the FedOne open source
> project).
>
> FedOne began in July 2009 in order to accelerate adoption of the wave
> federation protocol, and serve as a proof of concept that a non-Google
> implementation of the wave federation protocol could interoperate with the
> Google production instance. It worked. FedOne's existence lead to a
> prototype by Novell that demonstrated federation between Google Wave and
> Novell Pulse (now known as Vibe). In addition, in May of 2010, SAP unveiled
> a prototype version of SAP StreamWork that federated with both Novell Pulse
> and Google Wave. All three syste

Re: JavaHL package namespace / migration / compatability

[Christopher Brind]

I can understand why Subversion should be made a top level project quickly,
but I personally believe the namespace change is a reasonable request in
order to graduate for all the same reasons that convinced me Pivot should
change its namespace.

It sends the wrong message not to change given the importance of the Apache
namespace, imho.

Regards,
Chris

On 18 Nov 2009 05:18, "Brett Porter"  wrote:

On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote: > On Wed, Nov 18, 2009 at
12:06 AM, Justin Erenkr...
Handling case by case is valuable.

If it were com.somecompany.foo.* then there might be cause for concern in
that it might not appear independent.

I'm fine with Subversion keeping the current namespace, under the
understanding that migrating in the future in a way that makes sense for
their users is a good thing to do. This is similar to when a subproject goes
TLP too - for example, I work on Archiva, which came from Maven, which is
partially org.apache.maven.archiva.* and partially org.apache.archiva.*.

- Brett

- To
unsubscribe, e-mail: genera...