Re: ASF Board Report for Fluo - Initial Reminder for August 2017

[Christopher]

On Fri, Aug 11, 2017 at 11:21 AM Keith Turner <ke...@deenlo.com> wrote:

> On Wed, Aug 9, 2017 at 1:34 PM, Christopher <ctubb...@apache.org> wrote:
> > On Wed, Aug 9, 2017 at 10:41 AM Keith Turner <ke...@deenlo.com> wrote:
> >
> >> On Tue, Aug 8, 2017 at 7:36 PM, Christopher <ctubb...@apache.org>
> wrote:
> >> > On Tue, Aug 8, 2017 at 5:47 PM Keith Turner <ke...@deenlo.com> wrote:
> >> >>
> >> >> For reference I used the following to collect stats
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+closed%3A%3E%3D2017-05-01+
> >> >>
> >> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+created%3A%3E%3D2017-05-01+
> >> >>
> >> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Apr+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+closed%3A%3E%3D2017-05-01+
> >> >>
> >> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Apr+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+created%3A%3E%3D2017-05-01+
> >> >> git log --since 2017-05-01 | grep Author | sort -u
> >> >>
> >> >> On Tue, Aug 8, 2017 at 5:46 PM, Keith Turner <ke...@deenlo.com>
> wrote:
> >> >> > Here is a draft of the report
> >> >> >
> >> >> > ## Description:
> >> >> >
> >> >> >  - Apache Fluo is an open source implementation of Percolator
> (which
> >> >> > populates
> >> >> >Google's search index) for Apache Accumulo. With Fluo, users can
> >> >> > continuously
> >> >> >join new data into large existing data sets without reprocessing
> >> all
> >> >> > data.
> >> >> >Unlike batch and streaming frameworks, Fluo offers much lower
> >> latency
> >> >> > and can
> >> >> >operate on extremely large data sets.
> >> >
> >> >
> >> > I'm not a big fan of this description. There's some elements of
> debatable
> >> > accuracy and relevancy. I suggest dropping the history/background and
> >>
> >> What do you think is inaccurate?
> >>
> >>
>
> Good feedback and discussion, definitely influenced what I put in the
> report.  I never responded because I was in a time crunch trying to
> get the report out the door.  I am going to open an issue to improve
> the intro on the website based in this discussion.
>
> > It's not that it's inaccurate... it's that it's temporal. Saying that it
> > offers "much lower latency" compared to others is not likely to be a
> > resilient statement as advances in those other frameworks progress. It
> may
>
> I think its reasonable to write things that one believes are presently
> true.  If there is a concern can always explicitly state its subject
> to change.
>
> > be true... but it could not be true at any given moment. Same with "can
> > operate on extremely large data sets"... it's not necessarily accurate to
> > say this is "unlike" others, because others may be able to do that, too,
> at
> > any given moment.
> >
> > More importantly, I think, is whether or not these are relevant. Our docs
> > can explain more details about history, background, prior technologies,
> and
> > comparisons with other things. Those things should not distract from
> > answering "What is *this* in front of me?" question. I especially think
>
> My goal for contextualizing was to explain "what is this in front of
> me" in relative terms.  Sometimes its easier to understand a thing
> relative to other things that you know.
>
>

Fair enough. However, I prefer in absolute terms, rather than relative to
other stuff, because I think it's better to not assume that the reader has
any such relatable knowledge.


> > this or the board report... the board isn't going to want to see an
> > explanation of what Percolator is, or an explanation of limitations in
> > other software... they just want a reminder of what this particular
> Apache
> > project is about.
> >
> >
> >>
> >> > comparison stuff, and using a more "get to the point" de

Re: ASF Board Report for Fluo - Initial Reminder for August 2017

[Christopher]

On Wed, Aug 9, 2017 at 10:41 AM Keith Turner <ke...@deenlo.com> wrote:

> On Tue, Aug 8, 2017 at 7:36 PM, Christopher <ctubb...@apache.org> wrote:
> > On Tue, Aug 8, 2017 at 5:47 PM Keith Turner <ke...@deenlo.com> wrote:
> >>
> >> For reference I used the following to collect stats
> >>
> >>
> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+closed%3A%3E%3D2017-05-01+
> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+created%3A%3E%3D2017-05-01+
> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Apr+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+closed%3A%3E%3D2017-05-01+
> >>
> >>
> https://github.com/issues?utf8=%E2%9C%93=is%3Apr+repo%3Aapache%2Ffluo+repo%3Aapache%2Ffluo-recipes+repo%3Aapache%2Ffluo-website+created%3A%3E%3D2017-05-01+
> >> git log --since 2017-05-01 | grep Author | sort -u
> >>
> >> On Tue, Aug 8, 2017 at 5:46 PM, Keith Turner <ke...@deenlo.com> wrote:
> >> > Here is a draft of the report
> >> >
> >> > ## Description:
> >> >
> >> >  - Apache Fluo is an open source implementation of Percolator (which
> >> > populates
> >> >Google's search index) for Apache Accumulo. With Fluo, users can
> >> > continuously
> >> >join new data into large existing data sets without reprocessing
> all
> >> > data.
> >> >Unlike batch and streaming frameworks, Fluo offers much lower
> latency
> >> > and can
> >> >operate on extremely large data sets.
> >
> >
> > I'm not a big fan of this description. There's some elements of debatable
> > accuracy and relevancy. I suggest dropping the history/background and
>
> What do you think is inaccurate?
>
>
It's not that it's inaccurate... it's that it's temporal. Saying that it
offers "much lower latency" compared to others is not likely to be a
resilient statement as advances in those other frameworks progress. It may
be true... but it could not be true at any given moment. Same with "can
operate on extremely large data sets"... it's not necessarily accurate to
say this is "unlike" others, because others may be able to do that, too, at
any given moment.

More importantly, I think, is whether or not these are relevant. Our docs
can explain more details about history, background, prior technologies, and
comparisons with other things. Those things should not distract from
answering "What is *this* in front of me?" question. I especially think
this or the board report... the board isn't going to want to see an
explanation of what Percolator is, or an explanation of limitations in
other software... they just want a reminder of what this particular Apache
project is about.


>
> > comparison stuff, and using a more "get to the point" description which
> lets
> > users know why they should care about Fluo, like:
> >
> > Apache Fluo is a distributed processing system which allows users to
> > continuously and incrementally join new data with extremely large
> existing
> > data sets without reprocessing all the data. It provides low-latency,
> > high-throughput data processing into Apache Accumulo, with cross-node
> > transaction support and a notification system to automatically process
> new
> > data with a user-defined workflow.
>
>
> Thinking about this some more base on your feedback, I think there are
> three different aspects that are important to communicate to someone
> trying to quickly decide if they should look into this further.
>
>  1 . What capabilities it offers to users
>  2. How it works
>  3. Context, how does it compare to other big data technologies.
>
> Below is a rough outline of an attempt to communicate these three aspects.
>
> Intro :
>
>   Apache Fluo is a distributed data processing system built on Apache
> Accumulo.
>
> Capabilities :
>
>   Fluo allows users to continuously join new data into large existing
> data sets without reprocessing all data.  With Fluo, users can keep
> multiple dependent derived data sets up to date as new data arrives.
> Changes to derived data sets can be emitted to external query or
> analytics systems.
>
> How it works :
>
>   Fluo achieves this by offering the ability to execute user defined
> cross node transactions when data changes.
>
> Context :
>
>   Fluo offers much lower latency than batch frame

Re: About fluo-bytes

[Christopher]

On Tue, Aug 8, 2017 at 1:33 PM Keith Turner <ke...@deenlo.com> wrote:

> On Fri, Aug 4, 2017 at 4:42 PM, Christopher <ctubb...@apache.org> wrote:
> > Fluoers,
> >
> > I created a fluo-bytes repository in GitBox[1], so we can try to create a
>
> This is great. I will take a stab at putting together the initial PR
> for the repo unless someone else was interested.
>
>
It was my intention to put some effort into this this week, but I don't
mind collaborating. I just don't want to be stuck doing only reviews. :)



> > dependency-free, standalone implementation of the basic Bytes features we
> > need, based on Keith's observations in his blog post[2].
>
> At some point we need to circle back to the openjdk discuss list and
> let them know we are working on this.  There were a few people there
> who expressed interest in a project like this.  Maybe we can do that
> after we get the basic readme and initial import up. Reading this post
> made me think of the readme a lot.
>
>
+1; do you have a link to that discuss thread? I'm not familiar with this,
and was not a participant.


> >
> > Over the next few weeks, I'd like to try to start using it to create a
> > small library of the following:
> >
> > * A ByteSequence interface (analogous to CharSequence)
> > * BytesBuilder (analogous to StringBuilder)
> > * an immutable Bytes implementation of ByteSequence (analogous to String)
> >
> > Maybe later, we can add useful InputStream and OutputStream
> implementations
> > and other useful tools, but it should always be a small library with a
> > narrow focus on manipulating byte sequences.
> >
> > The idea is that this will be semver, but will very strong prefer to
> avoid
> > ever going to a breaking 2.0 change, instead insuring it will be
> backwards
> > compatible for a *LONG* time, making it safe for use in other projects'
> > APIs.
>
> When creating the readme, it would be good to try to explain the
> rational for avoiding dropping methods.  I attempted that in my blog
> post, but not sure how well I did at getting the point across.  I
> think it would be best shown with an example that shows how it can be
> hard to use two projects where one uses newer methods and another uses
> older dropped methods.  Couple that with both projects having the
> library in their API and its a huge headache for any users of both
> libraries.
>
>
+1


> >
> > I think this library would be useful not only for Fluo's API, but as a
> > separate dependency-free library, it could be easily reused by many other
>
> We will also need to explain why dependencies are so important.  If
> their were dependencies they would also need to follow very strict API
> guarantees.  Having Java standard libs as the only dep is good because
> Java itself is very rigorous about its API.
>
> Another thing that will need to be explained well in the readme is the
> benefit of multiple APIs using the same immutable type, it avoids
> copies when going between APIs.
>
>
+1; it sounds like you've already got the README half written ;)


> > projects, such as Accumulo (and anybody else).
> >
> > [1]: https://github.com/apache/fluo-bytes
> > [2]: https://fluo.apache.org/blog/2016/11/10/immutable-bytes/
>

Re: New parent POM/build-resources release

[Christopher]

Its documentation is at http://code.revelc.net/impsort-maven-plugin/
I don't know if there's much to say about it. Could maybe just tweet a link
with a brief comment?

On Tue, Aug 8, 2017 at 2:05 PM Keith Turner <ke...@deenlo.com> wrote:

> It would be nice to write up a blog post about the new automatic
> import formatting.  Thats is really nice and makes contributing
> easier.  I recently saw a PR in another project where a lot of time
> was spent discussing changes to import statements.  We have also had
> this type of discussion in Fluo in the past.  Having this automated is
> a big time saver going forward and I don't think anyone even knows it
> happened.
>
> On Fri, Aug 4, 2017 at 2:57 PM, Christopher <ctubb...@apache.org> wrote:
> > Hi Fluoers,
> >
> > I'd like to knock out a new release of the fluo-parent POM and
> > build-resources jar next week now that we're out of incubation. If folks
> > can take a look at them, and make sure the checkstyle rules, formatter
> > rules, and any other common plugins are properly configured in the
> parent,
> > and the other fluo repos build against them correctly, I can put
> together a
> > release candidate early next week.
>

New parent POM/build-resources release

[Christopher]

Hi Fluoers,

I'd like to knock out a new release of the fluo-parent POM and
build-resources jar next week now that we're out of incubation. If folks
can take a look at them, and make sure the checkstyle rules, formatter
rules, and any other common plugins are properly configured in the parent,
and the other fluo repos build against them correctly, I can put together a
release candidate early next week.

Update Twitter profile

[Christopher]

Can somebody edit the twitter profile for ApacheFluo to drop the
"(incubating)" status?

Re: New 'fluo-yarn' repo

[Christopher]

Ah, I see. Seems like a good idea. Out of curiosity, what kind of
versioning scheme did you have in mind?

On Mon, Jul 17, 2017 at 4:38 PM Mike Walch <mwa...@apache.org> wrote:

> Yes.  Fluo-yarn will be on a different release schedule.  A new release of
> Fluo should in most cases not require a new release of fluo-yarn.  New
> releases of fluo-yarn will most likely be necessary to upgrade Apache Twill
> to support newer releases of Hadoop YARN.
>
> On Mon, Jul 17, 2017 at 4:26 PM Christopher <ctubb...@apache.org> wrote:
>
> > Is the idea to have fluo-yarn on a different release cycle?
> >
> >
> > On Mon, Jul 17, 2017 at 3:52 PM Mike Walch <mwa...@apache.org> wrote:
> >
> > > I would like to create new repo (called 'fluo-yarn') using Gitbox to
> hold
> > > code for launching Fluo applications in YARN.  This is related to my
> > recent
> > > pull request [1]. Does anyone have any objections to this?
> > >
> > > [1]: https://github.com/apache/incubator-fluo/pull/883
> > >
> >
>

Re: New 'fluo-yarn' repo

[Christopher]

Is the idea to have fluo-yarn on a different release cycle?


On Mon, Jul 17, 2017 at 3:52 PM Mike Walch  wrote:

> I would like to create new repo (called 'fluo-yarn') using Gitbox to hold
> code for launching Fluo applications in YARN.  This is related to my recent
> pull request [1]. Does anyone have any objections to this?
>
> [1]: https://github.com/apache/incubator-fluo/pull/883
>

Re: Fluo article

[Christopher]

Yeah, I saw that from a Google Alert. Neat! If there's a surge of interest
from Spark developers, we'll probably want to think about what kinds of
things we can add to make working with Fluo and Spark even better. I'm not
a big Spark user myself.

On Fri, Jul 7, 2017 at 5:10 PM Michael Wall  wrote:

> Just saw this
>
> http://www.i-programmer.info/news/136-open-source/10927-apache-fluo-improves-spark-integration.html
>

[NOTICE] IPMC VOTE on recommending Fluo graduation

[Christopher]

This is just a heads up for those not watching the Incubator mailing list,
that there is now an ongoing VOTE thread on the general incubator mailing
list for the IPMC to recommend the graduation resolution to the ASF board,
to graduate Fluo from the Incubator and establish it as a TLP.

This is a recommendation vote. If this vote passes, the next step is to
present the resolution to the board for approval, with the recommendation
of the IPMC.

See the following for information about this step:
https://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation

Link to VOTE thread:
https://lists.apache.org/thread.html/f4050631cf7f561b8ce648ac04d9b3c86a6972b2f5e3a84e4d6139a1@%3Cgeneral.incubator.apache.org%3E

Re: [DISCUSS] GitBox

[Christopher]

One more thought on this: if we switched, I'd want to take the opportunity
to move GitHub notifications to the notifications@ list. That allows people
to subscribe directly to GitHub for customizing their notification
settings, or to subscribe to the notifications@ list. It would help reduce
redundant messages for those subscribing to dev@

On Mon, Jun 5, 2017 at 1:45 PM Christopher <ctubb...@apache.org> wrote:

> (Note: CC'd Fluo dev list)
>
> Fluo recently switched to GitBox. I figured this experience might be
> useful to mention if Accumulo decides to do it:
>
> Pitfalls:
>
> 1. commits and notifications didn't get forwarded to their respective
> mailing lists properly at first; that was an incubator-specific issue that
> wouldn't apply if Accumulo moved
>
> 2. the website repo stopped updating the website; I believe that has been
> fixed (but haven't pushed a new website commit to test), and can probably
> be avoided by mentioning the git-based website in the request to move to
> GitBox (which I forgot to do)
>
> 3. I forgot to update the Jenkins builds for Fluo, so those were broken
> for a few days; trivial to fix, and Fluo mostly relies on Travis CI instead
> of Jenkins anyway
>
> 4. Since the URL changed, I had to update my ~/.gitconfig settings for the
> credential.helper with a second credential line, and type in my password
> once to save it in GNOME keyring daemon the first time I pushed a new
> commit:
>   [credential]
> helper = gnome-keyring
>   [credential "https://git-wip-us.apache.org/repos/asf/;]
> username = ctubbsii
>   [credential "https://gitbox.apache.org/repos/asf/;]
> username = ctubbsii
>
> 5. notifications may come from a different email address, so it may need
> to be white-listed by the moderators the first time it sends to the list
>
> Several benefits (some surprising):
>
> 1. Can self-serve Travis CI configuration, because Travis CI grants
> permissions based on whether you have write permission on the GitHub repo.
> This was a very cool benefit. We can now clear caches, and set up builds
> with more control (per-branch, pull requests, etc.) than before, without
> submitting trivial INFRA tickets.
>
> 2. Can assign issues/PRs to individuals as well as use labels, milestones,
> to make them more searchable; for Accumulo, this would only benefit PRs,
> because we're not using GH issues.
>
> 3. Can close issues.
>
> 4. Only the host name changed in the URLs. GitBox is set up exactly like
> git-wip, so that was very convenient. A simple find/replace was sufficient
> to update docs and config files with the new host name without changing the
> path to the repo on that host.
>
> 5. When pushing to the server, the git client receives and prints messages
> about the pre-/post-push actions that the server is doing, like triggering
> mailing list notifications. I found this to be pleasantly informative, and
> possibly useful for debugging.
>
> 6. A private GitHub team is created in the Apache GitHub organization for
> the Apache users who have registered their GitHub user name. This means
> that the whole team can be @mentioned in GitHub by a team member, and team
> members can more easily find their colleagues on GitHub (only works for
> those who have opted-in with their GitHub user name).
>
> 7. This wouldn't apply to Accumulo, but Fluo was able to close a long-open
> 1.0.0 milestone that we hadn't been able to close since moving the repo to
> ASF. In general, this allows milestone management in GitHub (may not ever
> matter for Accumulo).
>
> Unknowns:
>
> 1. One thing that's not known is how well the JIRA integration will
> migrate. I imagine it works fine, but Fluo doesn't use JIRA, so I can't
> speak to that.
>
> Overall:
>
> Overall, I think individual developer clones were easy to update, and it
> didn't seem to inconvenience anybody too much. I emailed the list with a
> one-liner to update the URL, and that seemed to be appreciated/helpful.
> (git remote set-url 
> https://gitbox.apache.org/repos/asf/). This wouldn't be necessary
> if INFRA made the old URL redirect to the new one, but such as it is, they
> have not done so.
>
> The switch enables a lot more self-service, putting things more under the
> control of the PMC/committers, so INFRA doesn't have to be involved for
> various minor things. I think this is better for the foundation, because
> less tedious issue-handling means INFRA can operate more efficiently,
> possibly at lower cost to the foundation.
>
> I'm regularly seeing new small benefits (like the Travis CI one) that I
> wasn't fully expecting. There has been no downside (other than the time I
> spent chatting with INFRA to fix the mailing list notifi

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] Fluo 1.1.0-incubating-rc1

[Christopher]

Oh, interesting. That seems wrong. The Maven convention is that the test
directory is supposed to contain code for testing that particular module.
If there's nothing to test, it shouldn't exist. A separate module with
integration test code should exist in src/main, like in Accumulo's
accumulo-test module. Breaking that Maven convention seems to be resulting
in confusing behavior of the maven-source-plugin and maven-javadoc-plugin.

On Mon, Jun 5, 2017 at 6:13 PM Keith Turner <ke...@deenlo.com> wrote:

> That module only has a src/test dir.  There is no src/main dir.  Maybe
> that is the cause.
>
> On Mon, Jun 5, 2017 at 5:55 PM, Christopher <ctubb...@apache.org> wrote:
> > Neither fluo-integration jar which is missing javadocs are included in
> the
> > lib directory either, so I'm guessing they're just for testing. I'd still
> > expect a javadoc and source jar for them, though.
> >
> > On Mon, Jun 5, 2017 at 5:43 PM Christopher <ctubb...@apache.org> wrote:
> >
> >> The good:
> >>
> >> GPG signatures, hashes, SHA1 in Jar metadata all look good.
> >> Source tarball matches SHA1 (except for generated DEPENDENCIES file from
> >> Apache parent POM)
> >> Tests with ITs pass
> >> DISCLAIMER and LICENSE files are present and good
> >>
> >> The bad:
> >>
> >> The NOTICE file has the wrong copyright date (says 2016; should be 2017,
> >> or 2016-2017 to be consistent with the generated NOTICE files in each
> jar's
> >> META-INF).
> >>
> >> The confusing/questionable:
> >>
> >> There's a few missing source and javadoc jars. I'm not sure if that's
> >> intended, or how it happened:
> >> fluo-integration-1.1.0-incubating-tests.jar is missing both
> corresponding
> >> source and javadoc jar
> >> fluo-integration-1.1.0-incubating.jar is missing a corresponding javadoc
> >> jar
> >>
> >> Several ERROR logs in the console during the build; probably expected,
> >> from tests, but it's confusing, and could possibly be tests which aren't
> >> checking for valid return codes or something. Could also just be a bad
> log
> >> configuration for the ITs:
> >>
> >> 2017-06-05 17:28:22,502 [config.FluoConfiguration] ERROR: Client
> >> properties should not be set in your configuration if MiniFluo is
> >> configured to start its own accumulo (indicated by
> fluo.mini.start.accumulo
> >> being set to true)
> >> 2017-06-05 17:29:48,251 [server.AbstractNonblockingServer$FrameBuffer]
> >> ERROR: Unexpected throwable while invoking!
> >> 2017-06-05 17:29:55,779 [server.AbstractNonblockingServer$FrameBuffer]
> >> ERROR: Read a frame size of 1633837924, which is bigger than the maximum
> >> allowable buffer size for ALL connections.
> >>
> >>
> >> On Mon, Jun 5, 2017 at 4:21 PM Keith Turner <ke...@deenlo.com> wrote:
> >>
> >>> +1
> >>>
> >>>  * sig and hashes all checked out
> >>>  * Was able to build and test Fluo Recipes, Stress test, and Webindex
> >>> against staging repo
> >>>  * Was able to run web index against tar ball from staging repo
> >>>  * source tar matches commit
> >>>
> >>>
> >>> On Fri, Jun 2, 2017 at 12:53 PM, Keith Turner <ke...@deenlo.com>
> wrote:
> >>> > Fluo Developers,
> >>> >
> >>> > Please consider the following candidate for Fluo 1.1.0-incubating.
> >>> >
> >>> > Git Commit:
> >>> > ad8ee492e2f435405f98d825781098c55186f4fb
> >>> > Branch:
> >>> > 1.1.0-incubating-rc1
> >>> >
> >>> > If this vote passes, a gpg-signed tag will be created using:
> >>> > git tag -f -m 'Apache Fluo 1.1.0-incubating' -s
> >>> rel/fluo-1.1.0-incubating \
> >>> > ad8ee492e2f435405f98d825781098c55186f4fb
> >>> >
> >>> > Staging repo:
> >>> https://repository.apache.org/content/repositories/orgapachefluo-1017
> >>> > Source (official release artifact):
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-source-release.tar.gz
> >>> > Binary:
> >>>
> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-bin.tar.gz
> >>> > (Append ".sha1", ".m

Re: [VOTE] Fluo 1.1.0-incubating-rc1

[Christopher]

Neither fluo-integration jar which is missing javadocs are included in the
lib directory either, so I'm guessing they're just for testing. I'd still
expect a javadoc and source jar for them, though.

On Mon, Jun 5, 2017 at 5:43 PM Christopher <ctubb...@apache.org> wrote:

> The good:
>
> GPG signatures, hashes, SHA1 in Jar metadata all look good.
> Source tarball matches SHA1 (except for generated DEPENDENCIES file from
> Apache parent POM)
> Tests with ITs pass
> DISCLAIMER and LICENSE files are present and good
>
> The bad:
>
> The NOTICE file has the wrong copyright date (says 2016; should be 2017,
> or 2016-2017 to be consistent with the generated NOTICE files in each jar's
> META-INF).
>
> The confusing/questionable:
>
> There's a few missing source and javadoc jars. I'm not sure if that's
> intended, or how it happened:
> fluo-integration-1.1.0-incubating-tests.jar is missing both corresponding
> source and javadoc jar
> fluo-integration-1.1.0-incubating.jar is missing a corresponding javadoc
> jar
>
> Several ERROR logs in the console during the build; probably expected,
> from tests, but it's confusing, and could possibly be tests which aren't
> checking for valid return codes or something. Could also just be a bad log
> configuration for the ITs:
>
> 2017-06-05 17:28:22,502 [config.FluoConfiguration] ERROR: Client
> properties should not be set in your configuration if MiniFluo is
> configured to start its own accumulo (indicated by fluo.mini.start.accumulo
> being set to true)
> 2017-06-05 17:29:48,251 [server.AbstractNonblockingServer$FrameBuffer]
> ERROR: Unexpected throwable while invoking!
> 2017-06-05 17:29:55,779 [server.AbstractNonblockingServer$FrameBuffer]
> ERROR: Read a frame size of 1633837924, which is bigger than the maximum
> allowable buffer size for ALL connections.
>
>
> On Mon, Jun 5, 2017 at 4:21 PM Keith Turner <ke...@deenlo.com> wrote:
>
>> +1
>>
>>  * sig and hashes all checked out
>>  * Was able to build and test Fluo Recipes, Stress test, and Webindex
>> against staging repo
>>  * Was able to run web index against tar ball from staging repo
>>  * source tar matches commit
>>
>>
>> On Fri, Jun 2, 2017 at 12:53 PM, Keith Turner <ke...@deenlo.com> wrote:
>> > Fluo Developers,
>> >
>> > Please consider the following candidate for Fluo 1.1.0-incubating.
>> >
>> > Git Commit:
>> > ad8ee492e2f435405f98d825781098c55186f4fb
>> > Branch:
>> > 1.1.0-incubating-rc1
>> >
>> > If this vote passes, a gpg-signed tag will be created using:
>> > git tag -f -m 'Apache Fluo 1.1.0-incubating' -s
>> rel/fluo-1.1.0-incubating \
>> > ad8ee492e2f435405f98d825781098c55186f4fb
>> >
>> > Staging repo:
>> https://repository.apache.org/content/repositories/orgapachefluo-1017
>> > Source (official release artifact):
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-source-release.tar.gz
>> > Binary:
>> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-bin.tar.gz
>> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
>> > a given artifact.)
>> >
>> > All artifacts were built and staged with:
>> > mvn release:prepare && mvn release:perform
>> >
>> > Signing keys are available at
>> https://www.apache.org/dist/incubator/fluo/KEYS
>> > (Expected fingerprint: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
>> >
>> > Release notes (in progress) can be found at:
>> > https://fluo.apache.org/.../1.1.0-incubating
>> >
>> > 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.1.0-incubating release of Apache Fluo.
>> >
>> > This vote will end on Mon Jun  5 17:00:00 UTC 2017
>> > (Mon Jun  5 13:00:00 EDT 2017 / Mon Jun  5 10:00:00 PDT 2017)
>> >
>> > 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-1017/
>> > # note the trailing slash is needed
>>
>

Re: [VOTE] Fluo 1.1.0-incubating-rc1

[Christopher]

The good:

GPG signatures, hashes, SHA1 in Jar metadata all look good.
Source tarball matches SHA1 (except for generated DEPENDENCIES file from
Apache parent POM)
Tests with ITs pass
DISCLAIMER and LICENSE files are present and good

The bad:

The NOTICE file has the wrong copyright date (says 2016; should be 2017, or
2016-2017 to be consistent with the generated NOTICE files in each jar's
META-INF).

The confusing/questionable:

There's a few missing source and javadoc jars. I'm not sure if that's
intended, or how it happened:
fluo-integration-1.1.0-incubating-tests.jar is missing both corresponding
source and javadoc jar
fluo-integration-1.1.0-incubating.jar is missing a corresponding javadoc jar

Several ERROR logs in the console during the build; probably expected, from
tests, but it's confusing, and could possibly be tests which aren't
checking for valid return codes or something. Could also just be a bad log
configuration for the ITs:

2017-06-05 17:28:22,502 [config.FluoConfiguration] ERROR: Client properties
should not be set in your configuration if MiniFluo is configured to start
its own accumulo (indicated by fluo.mini.start.accumulo being set to true)
2017-06-05 17:29:48,251 [server.AbstractNonblockingServer$FrameBuffer]
ERROR: Unexpected throwable while invoking!
2017-06-05 17:29:55,779 [server.AbstractNonblockingServer$FrameBuffer]
ERROR: Read a frame size of 1633837924, which is bigger than the maximum
allowable buffer size for ALL connections.


On Mon, Jun 5, 2017 at 4:21 PM Keith Turner  wrote:

> +1
>
>  * sig and hashes all checked out
>  * Was able to build and test Fluo Recipes, Stress test, and Webindex
> against staging repo
>  * Was able to run web index against tar ball from staging repo
>  * source tar matches commit
>
>
> On Fri, Jun 2, 2017 at 12:53 PM, Keith Turner  wrote:
> > Fluo Developers,
> >
> > Please consider the following candidate for Fluo 1.1.0-incubating.
> >
> > Git Commit:
> > ad8ee492e2f435405f98d825781098c55186f4fb
> > Branch:
> > 1.1.0-incubating-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -m 'Apache Fluo 1.1.0-incubating' -s
> rel/fluo-1.1.0-incubating \
> > ad8ee492e2f435405f98d825781098c55186f4fb
> >
> > Staging repo:
> https://repository.apache.org/content/repositories/orgapachefluo-1017
> > Source (official release artifact):
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-source-release.tar.gz
> > Binary:
> https://repository.apache.org/content/repositories/orgapachefluo-1017/org/apache/fluo/fluo/1.1.0-incubating/fluo-1.1.0-incubating-bin.tar.gz
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
> > a given artifact.)
> >
> > All artifacts were built and staged with:
> > mvn release:prepare && mvn release:perform
> >
> > Signing keys are available at
> https://www.apache.org/dist/incubator/fluo/KEYS
> > (Expected fingerprint: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >
> > Release notes (in progress) can be found at:
> > https://fluo.apache.org/.../1.1.0-incubating
> >
> > 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.1.0-incubating release of Apache Fluo.
> >
> > This vote will end on Mon Jun  5 17:00:00 UTC 2017
> > (Mon Jun  5 13:00:00 EDT 2017 / Mon Jun  5 10:00:00 PDT 2017)
> >
> > 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-1017/
> > # note the trailing slash is needed
>

Re: [DISCUSS] GitBox

[Christopher]

p open PRs that are being
> reviewed/worked on.  However, PRs can only be closed by the person that
> created it or by pushing an empty commit that closes them.  With GitBox,
> committers could close them on GitHub.
>
> GitBox would also be useful for the Accumulo-website Github page now. For
> 2.0, each documentation page has an "Edit this page" link.  See the page
> below for an example:
>
> https://accumulo.apache.org/docs/unreleased/getting-started/design
>
> This will hopefully lead to more PRs from users as the "Edit this page"
> link directs you to GitHub where can you to edit the markdown and submit a
> pull request without leaving GitHub.  When 2.0 gets released, it would nice
> to be able to merge/close these PRs too.
>
> On Thu, May 11, 2017 at 8:41 AM Michael Wall <mjw...@gmail.com> wrote:
>
> > Late to this thread, but wanted to offer my 2 cents.  Having done several
> > releases, the search and bulk edit features of Jira were really key.
> > Moving all those issues is really the worst part of doing a release,
> > because you have to open each one and try to understand enough about it
> to
> > make a decision.   Some tickets are assigned to 1.7, 1.8 and 2.0, some
> are
> > 1.8 and 2.0, some were only 1.8.  You have to bulk edit each distinct
> > combination. I am unsure what the GH would be except to edit them 1 by 1.
> > Although if we cleaned up old issues it wouldn't be as big a deal.
> >
> > I would be willing to try it out better GH integration.  I love the PR
> > review.
> >
> > Mike
> >
> > On Fri, May 5, 2017 at 7:54 PM Christopher <ctubb...@apache.org> wrote:
> >
> > > I agree with Mike here, but to be clear, that's not what I was
> proposing.
> > > :)
> > >
> > > On Fri, May 5, 2017 at 1:35 PM Mike Walch <mwa...@apache.org> wrote:
> > >
> > > > I prefer GithHub issues over JIRA. Apache JIRA is slow, has a bloated
> > UI,
> > > > and it's annoying that it doesn't remember my session and I have to
> > > > re-login daily. I think new developers (esp those unfamiliar with
> > Apache)
> > > > are more likely to report/work on issues if they were on GitHub as
> most
> > > > non-Apache projects use GitHub and Apache JIRA requires an extra
> > account.
> > > > I understand two issue trackers can be pain (esp for the person
> > creating
> > > > release notes) but I would rather encourage more issue reporting and
> > > > contributions then speed up the process of creating release notes. We
> > > could
> > > > also move over the remaining open JIRA issues if GH issues became
> more
> > > > heavily used.
> > > >
> > > > On Fri, May 5, 2017 at 1:09 PM Josh Elser <josh.el...@gmail.com>
> > wrote:
> > > >
> > > > > (just making sure my point is clear and that Mike's is another
> unique
> > > > > point that I hadn't actually considered..)
> > > > >
> > > > > I meant confusion about what information would be encapsulated in
> > JIRA
> > > > > and what information would be encapsulated in GH metadata.
> > > > >
> > > > > e.g. we missed issue $x in the 2.x.x. release notes because it had
> > the
> > > > > "releasenotes" GH label and not a "releasenotes" JIRA label (or
> vice
> > > > > versa). I think a similar issue would come up with "fixVersion" and
> > > > > "milestone".
> > > > >
> > > > > Our use of JIRA is pretty well hashed out, and I think it works
> well
> > > for
> > > > > us. To my earlier point, without a specific hole in our current
> > > process,
> > > > > this just seems likely to create confusion about how to use it. The
> > > > > points you referenced to me don't seem virulent enough to justify
> the
> > > > > switch.
> > > > >
> > > > > Mike Drob wrote:
> > > > > > Changing the repo URL seems fairly disruptive to me, fwiw. Would
> > need
> > > > to
> > > > > > send notice to the dev list with instructions how to update your
> > git
> > > > > > remotes probably.
> > > > > >
> > > > > > On Fri, May 5, 2017, 10:30 AM Christopher<ctubb...@apache.org>
> > > wrote:
> > > > > >
> > > > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<josh.

Re: Welcome new committer/IPMC member Chris McTague

[Christopher]

Congrats!

(Also, to clarify, we mean PPMC, which is the Fluo podling portion of
incubator. The IPMC typically refers to those who oversee all podlings.)

On Fri, Jun 2, 2017, 12:18 Mike Walch  wrote:

> Welcome, Chris!
>
> On Fri, Jun 2, 2017 at 12:03 PM Josh Elser  wrote:
>
> > Welcome and congrats, Chris!
> >
> > On 6/2/17 10:41 AM, Keith Turner wrote:
> > > The Incubator Project Management Committee (IPMC) for Apache Fluo
> > > has invited Chris McTague to become a committer/IPMC member and we
> > > are pleased to announce that he has accepted.
> > >
> > > Chris, feel free to say a few words about your development interests.
> > >
> >
>

Re: Testing for 1.1.0 release

[Christopher]

Can only assign to committers.

On Wed, May 17, 2017, 15:37 Keith Turner  wrote:

> I tried assigning that issue to you (we now have gitbox), but was
> unable too.  Seems there is only a set list that we can assign to.
>
> On Wed, May 17, 2017 at 3:30 PM, Michael Wall  wrote:
> > I am going to work https://github.com/apache/incubator-fluo/issues/827
> > (Bytes.copyTo)
> > tomorrow, but you shouldn't hold up testing.
> >
> > On Wed, May 17, 2017 at 3:24 PM Keith Turner  wrote:
> >
> >> I have been running some quick test of Webindex[1] and Stresso[2]
> >> against 1.1.0-SNAPSHOT and have found a few bugs.  I am going to run
> >> some longer test on EC2 in preparation for a 1.1.0 release.  Before I
> >> do this, I wanted to see if anyone had an changes they would like to
> >> make before  this 1.1.0 testing is done.  Let me know of anything and
> >> I can hold off on testing.
> >>
> >> [1]: https://github.com/astralway/webindex
> >> [2]: https://github.com/astralway/stresso
> >>
>

Re: Repository Moves (updated git URLs)

[Christopher]

Okay. Linking would have also been reasonable. ☺️

On Tue, May 16, 2017, 15:22 Keith Turner <ke...@deenlo.com> wrote:

> ok, I closed the issue I opened as a duplicate
>
> On Tue, May 16, 2017 at 2:49 PM, Christopher <ctubb...@apache.org> wrote:
> > Yep, was discussing this with Chris on the original jira issue.
> >
> > On Tue, May 16, 2017, 14:45 Keith Turner <ke...@deenlo.com> wrote:
> >
> >> Notifications seem to be going to the wrong list.  I opened :
> >>
> >>
> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-14169
> >>
> >> On Fri, May 12, 2017 at 4:52 PM, Christopher <ctubb...@apache.org>
> wrote:
> >> > Hi all,
> >> >
> >> > Fluo's repositories have moved to GitBox[1], a newer Git service
> provided
> >> > by Apache which has a few new features than the old one. As a result,
> the
> >> > URLs have changed. You should update your local clones, Jenkins
> builds,
> >> CI
> >> > stuffs, etc. to point to the new location. We will be updating our
> >> website
> >> > docs, pom.xml files, and other references to our git repos soon with
> the
> >> > new URLs.
> >> >
> >> > The new URLs can be updated (assuming your git remote is called
> "origin")
> >> > similar to:
> >> >
> >> > (cd incubator-fluo && git remote set-url origin
> >> > https://gitbox.apache.org/repos/asf/incubator-fluo)
> >> > (cd incubator-fluo-recipes && git remote set-url origin
> >> > https://gitbox.apache.org/repos/asf/incubator-fluo-recipes)
> >> > (cd incubator-fluo-website && git remote set-url origin
> >> > https://gitbox.apache.org/repos/asf/incubator-fluo-website)
> >> >
> >> > [1]: https://issues.apache.org/jira/browse/INFRA-14121
> >>
>

Re: Repository Moves (updated git URLs)

[Christopher]

Has anybody tried a website update? Kinda want to make sure that still
works, too.

On Tue, May 16, 2017, 14:48 Christopher <ctubb...@apache.org> wrote:

> Yep, was discussing this with Chris on the original jira issue.
>
> On Tue, May 16, 2017, 14:45 Keith Turner <ke...@deenlo.com> wrote:
>
>> Notifications seem to be going to the wrong list.  I opened :
>>
>> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-14169
>>
>> On Fri, May 12, 2017 at 4:52 PM, Christopher <ctubb...@apache.org> wrote:
>> > Hi all,
>> >
>> > Fluo's repositories have moved to GitBox[1], a newer Git service
>> provided
>> > by Apache which has a few new features than the old one. As a result,
>> the
>> > URLs have changed. You should update your local clones, Jenkins builds,
>> CI
>> > stuffs, etc. to point to the new location. We will be updating our
>> website
>> > docs, pom.xml files, and other references to our git repos soon with the
>> > new URLs.
>> >
>> > The new URLs can be updated (assuming your git remote is called
>> "origin")
>> > similar to:
>> >
>> > (cd incubator-fluo && git remote set-url origin
>> > https://gitbox.apache.org/repos/asf/incubator-fluo)
>> > (cd incubator-fluo-recipes && git remote set-url origin
>> > https://gitbox.apache.org/repos/asf/incubator-fluo-recipes)
>> > (cd incubator-fluo-website && git remote set-url origin
>> > https://gitbox.apache.org/repos/asf/incubator-fluo-website)
>> >
>> > [1]: https://issues.apache.org/jira/browse/INFRA-14121
>>
>

Repository Moves (updated git URLs)

[Christopher]

Hi all,

Fluo's repositories have moved to GitBox[1], a newer Git service provided
by Apache which has a few new features than the old one. As a result, the
URLs have changed. You should update your local clones, Jenkins builds, CI
stuffs, etc. to point to the new location. We will be updating our website
docs, pom.xml files, and other references to our git repos soon with the
new URLs.

The new URLs can be updated (assuming your git remote is called "origin")
similar to:

(cd incubator-fluo && git remote set-url origin
https://gitbox.apache.org/repos/asf/incubator-fluo)
(cd incubator-fluo-recipes && git remote set-url origin
https://gitbox.apache.org/repos/asf/incubator-fluo-recipes)
(cd incubator-fluo-website && git remote set-url origin
https://gitbox.apache.org/repos/asf/incubator-fluo-website)

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

[DISCUSS] GitBox

[Christopher]

Hi all, it looks like https://gitbox.apache.org is up and running.

>From what I understand, this provides bi-directional mirroring between
GitHub repos and ASF repos, and would allow us to manage GitHub issues and
PRs by adding labels and milestones to them.

I think Fluo could really benefit from this, especially since we're already
using GitHub for issue tracking, and we really need labels and milestones.

I think we should put in a request to transition our repos over from the
current git service. They have replied to me that they'll work requests on
a first-come first-serve basis.

Re: Podling Report Reminder - May 2017

[Christopher]

+1, thanks Keith, and Josh for the quick signoff.

On Tue, May 2, 2017, 14:24 Josh Elser  wrote:

> Ditto. Thanks!
>
> Mike Walch wrote:
> > Looks great.  Thanks Keith!
> >
> > On Tue, May 2, 2017 at 2:03 PM Keith Turner  wrote:
> >
> >> I updated the Wiki.  Let me know of any desired mutations.
> >>
> >> https://wiki.apache.org/incubator/May2017
> >>
> >> On Mon, May 1, 2017 at 10:22 AM, Josh Elser
> wrote:
> >>> *ping*
> >>>
> >>> Don't forget, please! Due this Wednesday.
> >>>
> >>>
> >>> johndam...@apache.org 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, 17 May 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, May 03).
> 
>  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/May2017
> 
>  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: third party service to poll Fluo for absence of event

[Christopher]

On Wed, Feb 1, 2017 at 10:04 AM Meier, Caleb <caleb.me...@parsons.com>
wrote:

> Yeah, this seems pretty reasonable to me.  I guess it then boils down to
> the nitty gritty of do I store results in Fluo and have my service query
> Fluo (I think you guys actually advise against that in your documentation),
> or export results and then have the service query some external index that
> I am exporting to.
>
>
I'm not sure we advise against it, so much as recognize that it may not be
suitable for certain use cases and may not meet query performance
expectations (
http://fluo.apache.org/docs/fluo-recipes/1.0.0-incubating/export-queue/).

In any case, your observer need not write the final "last occurrence"
entries into a Fluo table. It could write them anywhere.


> Regarding timestamps, does the oracle server provide actual timestamps or
> just logical timestamps?  That is, could I use the timestamps that the
> server provides to define some sort of now() function to obtain the current
> time to compare with the times of incoming events?
>

Just logical time, and it delivers batches to limit locking, so it can
appear to jump ahead spontaneously. I'm not sure the OracleServer is
suitable for this purpose. What level of precision are you going for? It
might be enough to just run NTP, if you don't need more precision than
"within seconds".


> 
> From: Christopher <ctubb...@apache.org>
> Sent: Tuesday, January 31, 2017 5:08 PM
> To: dev@fluo.incubator.apache.org
> Subject: Re: third party service to poll Fluo for absence of event
>
> You could write an observer which rolls up timestamps from all the events
> you are concerned about, and puts the most recent event timestamp into a
> centralized place, which you could poll. If there is no ingest of these
> events, then the last timestamp in this central place will exceed some
> threshold and the poller could detect that and trigger additional actions.
>
> On Tue, Jan 31, 2017 at 3:51 PM Meier, Caleb <caleb.me...@parsons.com>
> wrote:
>
> > Hello,
> >
> > I’m looking into using Fluo to develop an event based notification system
> > that incrementally generates events of increasing complexity.  The one
> > issue that I’m running into is how to handle the non-event event.  That
> is,
> > Fluo (as I understand it) is not well-suited to handle the following
> > request: “generate a notification if no events of a given type have
> > occurred within the last 24 hours”.  This is because it is a push based
> > notification framework that only generates notifications when things
> > actually happen.  So the question is, has anyone looked into developing a
> > service for generating notifications at regular intervals (even if
> > something doesn’t happen) that works with Fluo?  I’m toying with the idea
> > of creating some sort of Twill application that tells Fluo to wake up at
> > regular intervals to generate a notification about the set of events
> > falling within the given time window. Before doing this I just wanted to
> > make sure that something like this does not already exist, and I also
> want
> > to get a sense of how bad an idea it is to delegate some of the logic of
> > this periodic notification service to Fluo.   Would it be better to
> > separate out the temporal portion of my notification request to be
> > processed entirely outside of Fluo to avoid transactional overhead?
> >
> > Caleb A. Meier, Ph.D.
> > Software Engineer II ♦ Analyst
> > Parsons Corporation
> > 1911 N. Fort Myer Drive, Suite 800 ♦ Arlington, VA 22209
> > Office:  (703)797-3066 <(703)%20797-3066> <(703)%20797-3066>
> > caleb.me...@parsons.com<mailto:caleb.me...@parsons.com> ♦
> www.parsons.com<
> > http://www.parsons.com/>
> >
> > --
> Christopher
>
-- 
Christopher

Re: Podling Report Reminder - February 2017

[Christopher]

+1

I was hoping to start a graduation discussion at some point, and thought
that make it into a report, but maybe next time.

In particular, I don't know that there is much left for us to learn in
incubation. The biggest issue is growth... and I think incubation can only
go so far in helping with that. It might be worth discussing graduation,
with a potential landing point as a sub-project of the Accumulo PMC, if
they are willing to support us as a sub-project. In that way, we could
inherit a larger voting base for basic release verification, in case that's
a risk of us being on our own. I don't think there's a serious risk of the
project dying... but there might be a serious risk of us failing to meet
TLP expectations for growth. Every project grows at a different pace, and
Fluo just might happen to be on the very slow end of that scale.

On Wed, Feb 1, 2017 at 11:21 AM Mike Walch <mwa...@gmail.com> wrote:

> Looks great.  Thanks Keith!
>
> On Wed, Feb 1, 2017 at 10:48 AM Keith Turner <ke...@deenlo.com> wrote:
>
> > I updated the Fluo report on the wiki.  Does anyone have any suggested
> > changes?
> >
> > https://wiki.apache.org/incubator/February2017
> >
> > On Tue, Jan 31, 2017 at 10:02 PM,  <johndam...@apache.org> 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, 15 February 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, February 01).
> > >
> > > 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.
> > >
> > > This should be appended to the Incubator Wiki page at:
> > >
> > > https://wiki.apache.org/incubator/February2017
> > >
> > > 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
> >
>
-- 
Christopher

Re: third party service to poll Fluo for absence of event

[Christopher]

You could write an observer which rolls up timestamps from all the events
you are concerned about, and puts the most recent event timestamp into a
centralized place, which you could poll. If there is no ingest of these
events, then the last timestamp in this central place will exceed some
threshold and the poller could detect that and trigger additional actions.

On Tue, Jan 31, 2017 at 3:51 PM Meier, Caleb <caleb.me...@parsons.com>
wrote:

> Hello,
>
> I’m looking into using Fluo to develop an event based notification system
> that incrementally generates events of increasing complexity.  The one
> issue that I’m running into is how to handle the non-event event.  That is,
> Fluo (as I understand it) is not well-suited to handle the following
> request: “generate a notification if no events of a given type have
> occurred within the last 24 hours”.  This is because it is a push based
> notification framework that only generates notifications when things
> actually happen.  So the question is, has anyone looked into developing a
> service for generating notifications at regular intervals (even if
> something doesn’t happen) that works with Fluo?  I’m toying with the idea
> of creating some sort of Twill application that tells Fluo to wake up at
> regular intervals to generate a notification about the set of events
> falling within the given time window. Before doing this I just wanted to
> make sure that something like this does not already exist, and I also want
> to get a sense of how bad an idea it is to delegate some of the logic of
> this periodic notification service to Fluo.   Would it be better to
> separate out the temporal portion of my notification request to be
> processed entirely outside of Fluo to avoid transactional overhead?
>
> Caleb A. Meier, Ph.D.
> Software Engineer II ♦ Analyst
> Parsons Corporation
> 1911 N. Fort Myer Drive, Suite 800 ♦ Arlington, VA 22209
> Office:  (703)797-3066 <(703)%20797-3066>
> caleb.me...@parsons.com<mailto:caleb.me...@parsons.com> ♦ www.parsons.com<
> https://webportal.parsons.com/,DanaInfo=www.parsons.com+>
>
> --
Christopher

Re: Doing twitter wrong

[Christopher]

These might be helpful:

http://hubshout.com/?Why-don%27t-my-Twitter-hashtags-show-up-in-Twitter-search=732
https://support.twitter.com/articles/66018


On Mon, Nov 14, 2016 at 9:54 AM Keith Turner  wrote:

> I sent out a tweet[1] with the hashtag #apachefluotour.  The tweet
> does not show up in search[2].  Not sure why.
>
> [1]: https://twitter.com/rkturn2/status/796897289566650368
> [2]: https://twitter.com/hashtag/apachefluotour
>

Re: Podling Report Reminder - November 2016

[Christopher]

I do think it would be helpful to label our issues with tags, like
"newbie". That's still a limitation imposed by INFRA with our preferred
choice of issue tracker.

On Tue, Nov 1, 2016 at 10:57 PM Christopher <ctubb...@apache.org> wrote:

> I think growing our community is really the only outstanding area of
> concern (with respect to graduation) that we need to work on. However, I'm
> not sure how we can do that. One thing is that we could reach out to Rya,
> and any other developers who are using Fluo that we know about, to
> explicitly invite them (rather than wait for them to come to us).
>
> Aside from that, I'm not sure what else we can do. Maybe we could spend
> some dev cycles on packaging and blogging about how to use the software
> more (with examples) to help lower the barrier to entry and to highlight
> use cases?
>
> On Tue, Nov 1, 2016 at 10:16 PM Josh Elser <josh.el...@gmail.com> wrote:
>
> Thanks for posting, Keith. A couple of thoughts:
>
> * Growing the community is probably worth a few spots on the top-3
> things to do
> * Lots of good things are written up that Fluo has done, but nothing on
> how you intend to grow Fluo beyond the current size.
>
> Good enough to sign off, but this is the area of most importance to
> focus on now that you have a cadence for releases.
>
> - Josh
>
> Keith Turner wrote:
> > I just udpated the wiki if anyone wants to review the changes.
> >
> > On Mon, Oct 31, 2016 at 3:56 PM, Josh Elser<josh.el...@gmail.com>
> wrote:
> >> I know you're already in a writing "mood", Keith.
> >>
> >> Don't forget about this one, please. Needs to be done by Wednesday this
> week
> >> (48hrs).
> >>
> >>
> >> johndam...@apache.org 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 November 2016, 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, November 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.
> >>>
> >>> This should be appended to the Incubator Wiki page at:
> >>>
> >>> http://wiki.apache.org/incubator/November2016
> >>>
> >>> 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: Podling Report Reminder - November 2016

[Christopher]

I think growing our community is really the only outstanding area of
concern (with respect to graduation) that we need to work on. However, I'm
not sure how we can do that. One thing is that we could reach out to Rya,
and any other developers who are using Fluo that we know about, to
explicitly invite them (rather than wait for them to come to us).

Aside from that, I'm not sure what else we can do. Maybe we could spend
some dev cycles on packaging and blogging about how to use the software
more (with examples) to help lower the barrier to entry and to highlight
use cases?

On Tue, Nov 1, 2016 at 10:16 PM Josh Elser  wrote:

Thanks for posting, Keith. A couple of thoughts:

* Growing the community is probably worth a few spots on the top-3
things to do
* Lots of good things are written up that Fluo has done, but nothing on
how you intend to grow Fluo beyond the current size.

Good enough to sign off, but this is the area of most importance to
focus on now that you have a cadence for releases.

- Josh

Keith Turner wrote:
> I just udpated the wiki if anyone wants to review the changes.
>
> On Mon, Oct 31, 2016 at 3:56 PM, Josh Elser  wrote:
>> I know you're already in a writing "mood", Keith.
>>
>> Don't forget about this one, please. Needs to be done by Wednesday this
week
>> (48hrs).
>>
>>
>> johndam...@apache.org 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 November 2016, 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, November 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.
>>>
>>> This should be appended to the Incubator Wiki page at:
>>>
>>> http://wiki.apache.org/incubator/November2016
>>>
>>> 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: Nice Report...

[Christopher]

Hi John. Thanks for the advice.

I think we basically agreed among ourselves that editing on the Wiki, with
discussion on the list, as needed, was sufficient. But, that was really
early on, and if we want to grow, it makes sense to utilize the mailing
list for more discussions in advance.

I think we left that question about issues empty because we didn't have
any. Though, I suppose the answer could be "No", for clarity. :)

On Tue, Nov 1, 2016 at 10:21 PM John D. Ament  wrote:

> Fluo Podling,
>
> Thanks for posting your report.  Looks good.  A couple of notes from my
>  side (as shepherd).
>
> - Try wherever possible to post/discuss the report on your MLs before
> posting to the incubator wiki.  Its not a rule per se, but it helps ensure
> that you have community involvement (clicking in the wiki and finding the
> report makes it harder to review)
>
> - This question is empty if you can provide an answer "Any issues that the
> Incubator PMC (IPMC) or ASF Board wish/need to be aware of?"
>
> Please don't hesitate if you have any questions, I monitor podling mailing
> lists.
>
> John
>

Re: Podling Report Reminder - November 2016

[Christopher]

I can help with this tomorrow, too.

On Mon, Oct 31, 2016, 15:57 Josh Elser  wrote:

> I know you're already in a writing "mood", Keith.
>
> Don't forget about this one, please. Needs to be done by Wednesday this
> week (48hrs).
>
> johndam...@apache.org 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 November 2016, 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, November 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.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > http://wiki.apache.org/incubator/November2016
> >
> > 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: [VOTE] Apache Fluo Recipes 1.0.0-incubating-rc1

[Christopher]

+1

Verified sigs and hashes
mvn verify passes
Source tarball matches git commit (except expected DEPENDENCIES file added
by maven-remote-resources-plugin)
Jar manifests contain specified git commit
Jar sources and javadocs exist
Confirmed LICENSE, NOTICE, DISCLAIMER in source tarball
Manually inspected all jar MANIFEST.MF, LICENSE, and NOTICE files and all
look good to me


On Sat, Oct 22, 2016 at 12:39 AM Christopher <ctubb...@apache.org> wrote:

> What makes you think that jsr305 is not compatibly licensed? I spent some
> time investigating this and the following is what I found. Unless I've
> missed something, it looks like there's no issue with jsr305 as a
> dependency.
>
> * It looks to me like it's licensed under BSD. This is according to the
> findbugs project[1], which has been redistributing the artifact after it
> effectively went dormant[2]. The Google Groups set up for developing jsr305
> seems to confirm the developers had agreed to distribute it under this[3].
> * It looks like jsr305 is often incorrectly uploaded to Maven Central (by
> findbugs?) under AL2, which is the license in the POM for our dependency
> (version 3.0.0) [4]. It was once uploaded (again, seemingly incorrectly) as
> LGPL, but we're not using that version [5].
> * There is an outstanding GitHub issue for findbugs to clarify the
> license[6], because it looks like they've been mislabeling it when they
> redistribute. But, it's also possible that they've been able to relicense
> under AL2, and forgot to update their docs which still say it's BSD.
> * jsr305 is used by us during the build, as a test dependency. it looks
> like that's okay, since we're not bundling it[7].
> * It is also used as a compile and/or runtime transitive dependency via
> Apache Spark. Even if we did depend on it directly, it seems like it should
> be fine because it's an optional part of the project[8], as long as we're
> not bundling it, and we're not.
> * Is it a problem for Apache Spark to depend on this directly? If it's
> not, I can't imagine it would be for us to depend on it transitively,
> through them.
>
> [1]:
> https://github.com/findbugsproject/findbugs/blob/3.0.1/findbugs/licenses/LICENSE-jsr305.txt
> [2]: https://jcp.org/en/jsr/detail?id=305
> [3]: https://groups.google.com/forum/#!topic/jsr-305/gQWGmiWMjE8
> [4]:
> https://repo1.maven.org/maven2/com/google/code/findbugs/jsr305/3.0.0/jsr305-3.0.0.pom
> [5]:
> https://repo1.maven.org/maven2/com/google/code/findbugs/jsr305/1.3.8/jsr305-1.3.8.pom
> [6]: https://github.com/findbugsproject/findbugs/issues/128
> [7]: http://www.apache.org/legal/resolved.html#prohibited
> [8]: http://www.apache.org/legal/resolved.html#optional
>
>
> On Fri, Oct 21, 2016 at 6:37 PM Josh Elser <els...@apache.org> wrote:
>
> +1
>
> * Sigs/xsums OK
> * No binaries in release
> * KEYS is accurate
> * Can build from source
> * Direct dependencies OK (beware that you are transitively bringing in
> com.google.code.findbugs:jsr305:jar:3.0.0 which is not compatibly
> licensed -- this should be fixed in the future)
> * No Copyright notices
> * apache-rat:check passes
> * Can run all tests
> * Artifacts built from release appear to be appropriately licensed.
> * Commit is contained in repository
> * Would prefer to see apache-fluo-recipes as the name instead.
>
> - Josh
>
> Keith Turner wrote:
> > Fluo Developers,
> >
> > Please consider the following candidate for Fluo Recipes
> 1.0.0-incubating.
> >
> > Git Commit:
> >  682eff983f1fe6e60b75c36d3b2f782c6a93b155
> > Branch:
> >  1.0.0-incubating-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> >  git tag -f -m 'Apache Fluo Recipes 1.0.0-incubating' -s
> > rel/fluo-recipes-1.0.0-incubating \
> >  682eff983f1fe6e60b75c36d3b2f782c6a93b155
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1016
> > Source (official release artifact):
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1016/org/apache/fluo/fluo-recipes/1.0.0-incubating/fluo-recipes-1.0.0-incubating-source-release.tar.gz
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> > given artifact.)
> >
> > All artifacts were built and staged with:
> >  mvn release:prepare&&  mvn release:perform
> >
> > Signing keys are available at
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (Expected fingerprint: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >
> > Release notes (in progress) can be found at:
> > https://fluo.apache.org/.../1.0.0-incubating
> >
> > Please vote one o

Re: On Findbugs jsr305 (was Re: [VOTE] Apache Fluo Recipes 1.0.0-incubating-rc1)

[Christopher]

Aside from the reporter of that issue's understandable confusion about the
difference between FindBugs license itself and of something bundled with
FindBugs, the evidence seems overwhelming that the artifact is BSD:

- Original developers agreed to BSD on Google Groups forum
- Original repo (as archived on code.google.com) contains BSD LICENSE
- FindBugs repo where it's bundled declares it BSD
- RHEL/CentOS and Fedora RPMs all delcare it BSD
- LICENSE in the current maintainer's repo is BSD (relocated from
code.google.com)
- The current maintainer has acknowledged the incorrect AL2 license in the
Maven Central artifact and is willing to accept a PR to fix[1].

Even if it were LGPL, I still don't think there'd be an issue, because of
how we're using it as a build-dep and transitive-dep for an optional
feature.
If you still think there's an issue, let's please escalate to LEGAL for
resolution.

[1]: https://github.com/amaembo/jsr-305/issues/27


On Sun, Oct 23, 2016 at 2:47 PM Josh Elser <els...@apache.org> wrote:

> The ambiguity of the conversation you provided in [6] is exactly why I
> have this opinion. Unless one of the devs can definitively say "it is
> BSD", there's way too much mis-information for me to feel comfortable
> with it.
>
> Given the availability of
> https://stephenc.github.com/findbugs-annotations, it's a no-brainer to
> use that instead, IMO.
>
> Specifically to Fluo, I did not inspect its usage that closely. If it's
> only used at build time, then, as you point out, it's a non-issue.
>
> Christopher wrote:
> > What makes you think that jsr305 is not compatibly licensed? I spent some
> > time investigating this and the following is what I found. Unless I've
> > missed something, it looks like there's no issue with jsr305 as a
> > dependency.
> >
> > * It looks to me like it's licensed under BSD. This is according to the
> > findbugs project[1], which has been redistributing the artifact after it
> > effectively went dormant[2]. The Google Groups set up for developing
> jsr305
> > seems to confirm the developers had agreed to distribute it under
> this[3].
> > * It looks like jsr305 is often incorrectly uploaded to Maven Central (by
> > findbugs?) under AL2, which is the license in the POM for our dependency
> > (version 3.0.0) [4]. It was once uploaded (again, seemingly incorrectly)
> as
> > LGPL, but we're not using that version [5].
> > * There is an outstanding GitHub issue for findbugs to clarify the
> > license[6], because it looks like they've been mislabeling it when they
> > redistribute. But, it's also possible that they've been able to relicense
> > under AL2, and forgot to update their docs which still say it's BSD.
> > * jsr305 is used by us during the build, as a test dependency. it looks
> > like that's okay, since we're not bundling it[7].
> > * It is also used as a compile and/or runtime transitive dependency via
> > Apache Spark. Even if we did depend on it directly, it seems like it
> should
> > be fine because it's an optional part of the project[8], as long as we're
> > not bundling it, and we're not.
> > * Is it a problem for Apache Spark to depend on this directly? If it's
> not,
> > I can't imagine it would be for us to depend on it transitively, through
> > them.
> >
> > [1]:
> >
> https://github.com/findbugsproject/findbugs/blob/3.0.1/findbugs/licenses/LICENSE-jsr305.txt
> > [2]: https://jcp.org/en/jsr/detail?id=305
> > [3]: https://groups.google.com/forum/#!topic/jsr-305/gQWGmiWMjE8
> > [4]:
> >
> https://repo1.maven.org/maven2/com/google/code/findbugs/jsr305/3.0.0/jsr305-3.0.0.pom
> > [5]:
> >
> https://repo1.maven.org/maven2/com/google/code/findbugs/jsr305/1.3.8/jsr305-1.3.8.pom
> > [6]: https://github.com/findbugsproject/findbugs/issues/128
> > [7]: http://www.apache.org/legal/resolved.html#prohibited
> > [8]: http://www.apache.org/legal/resolved.html#optional
> >
> > On Fri, Oct 21, 2016 at 6:37 PM Josh Elser<els...@apache.org>  wrote:
> >
> >> +1
> >>
> >> * Sigs/xsums OK
> >> * No binaries in release
> >> * KEYS is accurate
> >> * Can build from source
> >> * Direct dependencies OK (beware that you are transitively bringing in
> >> com.google.code.findbugs:jsr305:jar:3.0.0 which is not compatibly
> >> licensed -- this should be fixed in the future)
> >> * No Copyright notices
> >> * apache-rat:check passes
> >> * Can run all tests
> >> * Artifacts built from release appear to be appropriately licensed.
> >> * Commit is contained in repository
> >> * Would prefer to see apache-fluo-recipes as t

Re: [VOTE] Fluo Recipes 1.0.0-incubating-rc0

[Christopher]

-1

* Reviewed signatures, hashes
* Commit matches tarball (with the exception of the generated DEPENDENCIES
file, which is created by the maven-remote-resources-plugin)
* Builds fine with tests, but with a compiler warning about unused
auto-closeable in FluoSparkHelperIT.java which should be fixed

Issues (minor):
* The NOTICE and DISCLAIMER files at the top incorrectly identifies itself
as Apache Fluo, rather than Apache Fluo Recipes. This might be okay with
DISCLAIMER (though, some wording to explain the relationship Apache Fluo
Recipes has to Apache Fluo would help, but it's certainly confusing for
NOTICE.
* The modules don't have the "Apache" branding in their  elements in
the pom. This results in NOTICE files that don't have the Apache branding
on the project name, and jar manifests which have the same. Also, the
generated NOTICE files in the jars for the modules look funny "Fluo Recipes
Accumulo". Should we name them more like "Fluo Recipes For Accumulo"?
* We can/should also update the  fields and NOTICE files to have "
(incubating)" suffixed at the end.

Other:

* saw weird Implementation-URLs in jar manifests. Not really sure these add
any value... but the URLs certainly shouldn't be expected to exist (they
don't)


On Tue, Oct 18, 2016 at 3:33 PM Christopher <ctubb...@apache.org> wrote:

> I'm reviewing this now, but wanted to mention that the branch didn't match
> the commit (it was one commit ahead), so I just now pushed a rollback of
> that 1 commit to the rc0 branch, and I staged that extra commit to an
> rc0-next branch.
>
> On Tue, Oct 18, 2016 at 2:24 PM Josh Elser <josh.el...@gmail.com> wrote:
>
> Keith Turner wrote:
> > On Tue, Oct 18, 2016 at 1:37 PM, Josh Elser<josh.el...@gmail.com>
> wrote:
> >> Keith Turner wrote:
> >>>> * Saw libthrift in the parent pom.xml, but could not see usages of
> that
> >>>>>   anywhere in the child modules. (not a release issue, just curious)
> >>>
> >>> Its in the dep mgmt section.  The reason is its needed to build
> >>> recipes against accumulo 1.8.0.  Fluo also uses thrift and depends on
> >>> 0.9.1.  If thrift 0.9.1 ends up on path, then MiniAccumulo will hang.
> >>> I can add a comment to the pom.
> >>>
> >> Ah, ok. I just did a grep and did see any usages of Thrift in the
> recipes
> >> which made me wonder why it was defined (even if only in depMgmt).
> >> Overriding Fluo's thrift dependency makes sense -- you don't need to
> >> document on my account.
> >
> > It took me a bit to remember why it was there. I made a PR to add a
> > comment to pom.
>
> Ok, sounds great, guys. I just assumed I was being dense and did not
> want to demand a comment to be added :)
>
>

Re: [VOTE] Fluo Recipes 1.0.0-incubating-rc0

[Christopher]

I'm reviewing this now, but wanted to mention that the branch didn't match
the commit (it was one commit ahead), so I just now pushed a rollback of
that 1 commit to the rc0 branch, and I staged that extra commit to an
rc0-next branch.

On Tue, Oct 18, 2016 at 2:24 PM Josh Elser  wrote:

> Keith Turner wrote:
> > On Tue, Oct 18, 2016 at 1:37 PM, Josh Elser
> wrote:
> >> Keith Turner wrote:
>  * Saw libthrift in the parent pom.xml, but could not see usages of
> that
> >   anywhere in the child modules. (not a release issue, just curious)
> >>>
> >>> Its in the dep mgmt section.  The reason is its needed to build
> >>> recipes against accumulo 1.8.0.  Fluo also uses thrift and depends on
> >>> 0.9.1.  If thrift 0.9.1 ends up on path, then MiniAccumulo will hang.
> >>> I can add a comment to the pom.
> >>>
> >> Ah, ok. I just did a grep and did see any usages of Thrift in the
> recipes
> >> which made me wonder why it was defined (even if only in depMgmt).
> >> Overriding Fluo's thrift dependency makes sense -- you don't need to
> >> document on my account.
> >
> > It took me a bit to remember why it was there. I made a PR to add a
> > comment to pom.
>
> Ok, sounds great, guys. I just assumed I was being dense and did not
> want to demand a comment to be added :)
>

Re: [VOTE] Fluo Recipes 1.0.0-incubating-rc0

[Christopher]

On Tue, Oct 18, 2016 at 1:37 PM Josh Elser  wrote:

> Keith Turner wrote:
> >> * Saw libthrift in the parent pom.xml, but could not see usages of that
> >> >  anywhere in the child modules. (not a release issue, just curious)
> >
> > Its in the dep mgmt section.  The reason is its needed to build
> > recipes against accumulo 1.8.0.  Fluo also uses thrift and depends on
> > 0.9.1.  If thrift 0.9.1 ends up on path, then MiniAccumulo will hang.
> > I can add a comment to the pom.
> >
>
> Ah, ok. I just did a grep and did see any usages of Thrift in the
> recipes which made me wonder why it was defined (even if only in
> depMgmt). Overriding Fluo's thrift dependency makes sense -- you don't
> need to document on my account.
>

Still nice to document for the next release.

Re: [VOTE] Fluo Recipes 1.0.0-incubating-rc0

[Christopher]

Were you intending this to be a vote thread or just a test? By convention,
I usually reserve rc0 for test of the release process itself, and rc1+ for
actual release candidates... but you may have something else in mind. I
just want to be sure before I prioritize testing this RC over other stuffs.

On Mon, Oct 17, 2016, 16:42 Mike Walch  wrote:

> +1
>
> * Verified signatures and hashes for source release
> * Verified that recipes jars exist in staging repo
> * Ran 'mvn verify' for stresso and webindex using staging repo
> * Ran webindex dev server using staging repo
>
> On Mon, Oct 17, 2016 at 2:08 PM Keith Turner  wrote:
>
> > Fluo Developers,
> >
> > Please consider the following candidate for Fluo Recipes
> 1.0.0-incubating.
> >
> > Git Commit:
> > 2eb367e173721607a2cb958927e3c753b40188ed
> > Branch:
> > 1.0.0-incubating-rc0
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -m 'Apache Fluo Recipes 1.0.0-incubating' \
> > -s rel/fluo-recipes-1.0.0-incubating \
> > 2eb367e173721607a2cb958927e3c753b40188ed
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1014
> >
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1014/org/apache/fluo/fluo-recipes/1.0.0-incubating/fluo-recipes-1.0.0-incubating-source-release.tar.gz
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> > given artifact.)
> >
> > All artifacts were built and staged with:
> > mvn release:prepare && mvn release:perform
> >
> > Signing keys are available at
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (Expected fingerprint: CF72 CA07 C8BC 86A1 C862  765F 9AAC FB56 352A
> CF76)
> >
> > Release notes (in progress) can be found at:
> > https://fluo.apache.org/.../1.0.0-incubating (not yet started)
> >
> > 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.0.0-incubating release of Apache Fluo.
> >
> > This vote will end on Thur Oct 20 18:10:00 UTC 2016
> > (Fri Oct 14:10:00 EDT 2016 / Fri Oct 20 11:10: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-1014/
> > # note the trailing slash is needed
> >
>

[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] Fluo 1.0.0-incubating-rc2

[Christopher]

This vote passes with +4. I'll be sending a vote email to the IPMC soon.

On Thu, Sep 29, 2016 at 5:01 PM Billie Rinaldi <bil...@apache.org> wrote:

> +1
> - signatures are good
> - builds from source and tests pass except GarbageCollectionIteratorIT
> - tarball matches tag
> - L look good
> - disclaimer is good and file names contain incubating
>
> On Tue, Sep 27, 2016 at 3:55 PM, Christopher <ctubb...@apache.org> wrote:
>
> > Fluo Developers,
> >
> > Please consider the following candidate for Fluo 1.0.0-incubating.
> >
> > Git Commit:
> > e1dbc608c67f31e804b59abd69d0bc530ca00f77
> > Branch:
> > 1.0.0-incubating-rc2
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -m 'Apache Fluo 1.0.0-incubating' -s
> > rel/fluo-1.0.0-incubating \
> > e1dbc608c67f31e804b59abd69d0bc530ca00f77
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1013
> > Source (official release artifact):
> > https://repository.apache.org/content/repositories/
> > orgapachefluo-1013/org/apache/fluo/fluo/1.0.0-incubating/
> > fluo-1.0.0-incubating-source-release.tar.gz
> > Binary:
> > https://repository.apache.org/content/repositories/
> > orgapachefluo-1013/org/apache/fluo/fluo/1.0.0-incubating/
> > fluo-1.0.0-incubating-bin.tar.gz
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> > given artifact.)
> >
> > All artifacts were built and staged with:
> > mvn release:prepare && mvn release:perform
> >
> > Signing keys are available at
> > https://www.apache.org/dist/incubator/fluo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > Release notes (in progress) can be found at:
> > https://fluo.apache.org/.../1.0.0-incubating (not yet started)
> >
> > 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.0.0-incubating release of Apache Fluo.
> >
> > This vote will end on Fri Sep 30 23:00:00 UTC 2016
> > (Fri Sep 30 19:00:00 EDT 2016 / Fri Sep 30 16:00: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-1013/
> > # note the trailing slash is needed
> >
>

Re: [VOTE] Fluo 1.0.0-incubating-rc1

[Christopher]

Technically, this vote doesn't expire until 1930EDT, but I don't plan on
voting on this one, and it doesn't look like it'll pass as-is. I'll create
an RC2 on Monday, if this vote fails.

On Fri, Sep 23, 2016 at 5:35 PM Keith Turner <ke...@deenlo.com> wrote:

> On Wed, Sep 21, 2016 at 11:13 PM, Josh Elser <els...@apache.org> wrote:
> > +1 (binding)
> >
> > First off, interesting use of the fetch.sh script to circumvent any extra
> > licensing in Fluo. I feel like this kind of goes against the intent of
> the
> > LICENSE and NOTICE files (they're meant to be there so that users know
> your
> > product depends on and those licenses), but I can't cite a reason why
> it's
> > against policy.
> >
> > * xsum/sigs OK
> > * no binary files in source-release
> > * apache-rat:check passes
> > * mvn verify passes (sans GarbageCollectionIteratorIT[1])
> > * DISCLAIMER is present
> > * L are fine
> > * KEYS present and contains the signing key
> > * SHA1 present in repo
> >
> > * I feel like you could easily add the license header to the
> docs/**/*.md,
> > but I know I've seen this go both ways.
>
> Just made this change
>
> > * I would like to see apache-fluo in the tarball names and directories
> > contained in the tarballs, but I've also argued at length with
> Christopher
> > about this in the past. I will probably continue to cite it as something
> I'd
> > like to see :)
> > * I would guess some people in IPMC would like to see your artifacats
> staged
> > to dist.a.o/repos/dist/dev/incubator/fluo but nothing wrong with
> references
> > from repo.a.o AFAIK
> >
> > Made a pass over the website and things look OK too. Will be happy to see
> > the two reference to "pre-ASF life" things removed promptly after
> > 1.0.0-incubating is released.
> >
> >
> > - Josh
> >
> > [1]
> >
> > ```
> > Running org.apache.fluo.integration.impl.GarbageCollectionIteratorIT
> > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 113.007
> sec
> > <<< FAILURE! - in
> > org.apache.fluo.integration.impl.GarbageCollectionIteratorIT
> >
> testGetOldestTimestamp(org.apache.fluo.integration.impl.GarbageCollectionIteratorIT)
> > Time elapsed: 21.67 sec  <<< FAILURE!
> > java.lang.AssertionError: expected:<0> but was:<2>
> > at
> >
> org.apache.fluo.integration.impl.GarbageCollectionIteratorIT.testGetOldestTimestamp(GarbageCollectionIteratorIT.java:194)
> > ```
> >
> > Christopher wrote:
> >>
> >> Fluo Developers,
> >>
> >> Please consider the following candidate for Fluo 1.0.0-incubating.
> >>
> >> Git Commit:
> >>  b07fbf8b755e8f555d06fe2d57db2868f9b20c1c
> >> Branch:
> >>  1.0.0-incubating-rc1
> >>
> >> If this vote passes, a gpg-signed tag will be created using:
> >>  git tag -f -m 'Apache Fluo 1.0.0-incubating' -s
> >> rel/fluo-1.0.0-incubating \
> >>  b07fbf8b755e8f555d06fe2d57db2868f9b20c1c
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/orgapachefluo-1012
> >> Source (official release artifact):
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachefluo-1012/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-source-release.tar.gz
> >> Binary:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachefluo-1012/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-bin.tar.gz
> >> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> >> given artifact.)
> >>
> >> All artifacts were built and staged with:
> >>  mvn release:prepare&&  mvn release:perform
> >>
> >> Signing keys are available at
> >> https://www.apache.org/dist/incubator/fluo/KEYS
> >> (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >>
> >> Release notes (in progress) can be found at:
> >> https://fluo.apache.org/.../1.0.0-incubating
> >>
> >> 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.0.0-incubating release of Apache Fluo.
> >>
> >> This vote will end on Fri Sep 23 23:30:00 UTC 2016
> >> (Fri Sep 23 19:30:00 EDT 2016 / Fri Sep 23 16: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-1012/
> >>  # note the trailing slash is needed
> >>
> >
>

[VOTE] Fluo 1.0.0-incubating-rc1

[Christopher]

Fluo Developers,

Please consider the following candidate for Fluo 1.0.0-incubating.

Git Commit:
b07fbf8b755e8f555d06fe2d57db2868f9b20c1c
Branch:
1.0.0-incubating-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Fluo 1.0.0-incubating' -s
rel/fluo-1.0.0-incubating \
b07fbf8b755e8f555d06fe2d57db2868f9b20c1c

Staging repo:
https://repository.apache.org/content/repositories/orgapachefluo-1012
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapachefluo-1012/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-source-release.tar.gz
Binary:
https://repository.apache.org/content/repositories/orgapachefluo-1012/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-bin.tar.gz
(Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
given artifact.)

All artifacts were built and staged with:
mvn release:prepare && mvn release:perform

Signing keys are available at
https://www.apache.org/dist/incubator/fluo/KEYS
(Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)

Release notes (in progress) can be found at:
https://fluo.apache.org/.../1.0.0-incubating

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.0.0-incubating release of Apache Fluo.

This vote will end on Fri Sep 23 23:30:00 UTC 2016
(Fri Sep 23 19:30:00 EDT 2016 / Fri Sep 23 16: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-1012/
# note the trailing slash is needed

Re: [TEST] Fluo 1.0.0-incubating-rc0

[Christopher]

One issue so far: I don't know where we're staging release notes.

On Wed, Sep 14, 2016 at 10:31 PM Christopher <ctubb...@apache.org> wrote:

> The following is a test of my script from
> https://github.com/apache/incubator-fluo/pull/769
> Please begin reviewing what it has produced so I can iron out the release
> process a bit, and so you can find any build-bugs prior to a release
> candidate vote with RC1.
>
> =
> Fluo Developers,
>
> Please consider the following candidate for Fluo 1.0.0-incubating.
>
> Git Commit:
> f7a7aaf194ec2c0bef85d97e7ce939232d9a1491
> Branch:
> 1.0.0-incubating-rc0
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Fluo 1.0.0-incubating' -s
> rel/fluo-1.0.0-incubating \
> f7a7aaf194ec2c0bef85d97e7ce939232d9a1491
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachefluo-1011
> Source (official release artifact):
> https://repository.apache.org/content/repositories/orgapachefluo-1011/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-source-release.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapachefluo-1011/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-bin.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys are available at
> https://www.apache.org/dist/incubator/fluo/KEYS
> (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>
> Release notes (in progress) can be found at:
> https://fluo.apache.org/.../1.0.0-incubating
>
> 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.0.0-incubating release of Apache Fluo.
>
> This vote will end on Sun Sep 18 02:30:00 UTC 2016
> (Sat Sep 17 22:30:00 EDT 2016 / Sat Sep 17 19: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-1011/
> # note the trailing slash is needed
>
>

[TEST] Fluo 1.0.0-incubating-rc0

[Christopher]

The following is a test of my script from
https://github.com/apache/incubator-fluo/pull/769
Please begin reviewing what it has produced so I can iron out the release
process a bit, and so you can find any build-bugs prior to a release
candidate vote with RC1.

=
Fluo Developers,

Please consider the following candidate for Fluo 1.0.0-incubating.

Git Commit:
f7a7aaf194ec2c0bef85d97e7ce939232d9a1491
Branch:
1.0.0-incubating-rc0

If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Fluo 1.0.0-incubating' -s
rel/fluo-1.0.0-incubating \
f7a7aaf194ec2c0bef85d97e7ce939232d9a1491

Staging repo:
https://repository.apache.org/content/repositories/orgapachefluo-1011
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapachefluo-1011/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-source-release.tar.gz
Binary:
https://repository.apache.org/content/repositories/orgapachefluo-1011/org/apache/fluo/fluo/1.0.0-incubating/fluo-1.0.0-incubating-bin.tar.gz
(Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
given artifact.)

All artifacts were built and staged with:
mvn release:prepare && mvn release:perform

Signing keys are available at
https://www.apache.org/dist/incubator/fluo/KEYS
(Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)

Release notes (in progress) can be found at:
https://fluo.apache.org/.../1.0.0-incubating

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.0.0-incubating release of Apache Fluo.

This vote will end on Sun Sep 18 02:30:00 UTC 2016
(Sat Sep 17 22:30:00 EDT 2016 / Sat Sep 17 19: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-1011/
# note the trailing slash is needed

Re: Better linking between asf and github

[Christopher]

We asked INFRA about MATT when we began incubation, but they said they were
not accepting additional pilot MATT projects at that time. (Can't find a
copy of that conversation right now to reference, though.)

On Wed, Sep 14, 2016 at 12:06 PM Josh Elser  wrote:

> Surprise :)
>
> Michael Wall wrote:
> > Ok, no worries.  Just saw it mentioned in a email about Netbeans joining
> > ASF.  Wait, what?
> >
> > On Wed, Sep 14, 2016 at 11:37 AM, Josh Elser
> wrote:
> >
> >> I think we had discussed this before (or I'm just projecting another
> >> project onto Fluo :P)
> >>
> >> Last I checked, Infra was short on cycles to accept new projects to join
> >> MATT, but maybe this has changed.
> >>
> >>
> >> Michael Wall wrote:
> >>
> >>> Has anyone looked into this MATT program?
> >>> https://reference.apache.org/committer/github.
> >>>
> >>> Seems kinda interesting for the right community.  Maybe a fit for
> fluo.  I
> >>> didn't see from that page whether it would allow you close tickets on
> >>> github or not.
> >>>
> >>>
> >
>

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

[Christopher]

I just now moved the KEYS file over to the dist/release area instead of the
dist/dev area. I figured there's no reason for it to stay in staging. It's
not really something which requires additional review before being mirrored.

On Sun, Aug 7, 2016 at 9:28 PM Christopher <ctubb...@apache.org> wrote:

> You're looking in the wrong place. The address is:
> https://dist.apache.org/repos/dist/dev/incubator/fluo (that's dist/dev/,
> not dist/release/)
> Also, that staging location is optional. I only put them there as a matter
> of convenience for those preferring to download from there rather than
> examine them in Nexus, and to make it easy to "release" with a simple "svn
> mv" later.
>
> The names for the tarballs were discussed in a previous thread on the
> incubator list. The names are derived from the artifactId names in their
> Maven coordinates. Modifying the tarballs to diverge from these doesn't
> make sense, because they won't match the actual artifacts in Maven Central,
> and that can cause a lot of confusion when users try to find the correct
> artifact for dependency resolution. Further, adding "apache-" as a prefix
> is redundant in the Maven coordinates because the groupId is
> org.apache.fluo. The "apache-" prefix is not required, and is not done by
> many Apache projects. Additionally, the build-resources artifact is
> actually just "build-resources" it does not have "fluo" in the name,
> because while the fluo parent POM uses it, and it is produced by the fluo
> team, it does not actually have anything to do with "fluo" software. It
> could be used by any project wishing to depend on the checkstyle/formatter
> rules it contains.
>
> So, yes, we could rename the artifactId so that "apache-" and
> "apache-fluo-" prefix these artifacts... but I think it's not necessary,
> adds redundancy to the maven coordinates, and doesn't actually seem to
> achieve any useful goal. As far as I can tell, the only thing I can tell
> that it actually accomplishes is make the file names ridiculously long.
>
> Also, if we don't do that this time, but rename the artifacts later, then
> we have the situation where you can't just update the version number to
> update to the next version... users actually have to start changing which
> artifact they are dependent on.
>
> On Sun, Aug 7, 2016 at 9:12 PM Josh Elser <els...@apache.org> wrote:
>
>> -1
>>
>> I do not see a published KEYS file for Fluo at
>> https://dist.apache.org/repos/dist/release/incubator/fluo (you don't
>> have the staging directory at all, actually). I am happy to switch this
>> to +1 after this file is made (VOTE doesn't need to fail).
>>
>> The good:
>>
>> * sigs/xsums match
>> * DISCLAIMER is present
>> * Files have correct license headers
>> * LICENSE and NOTICE are correct
>>
>> The "please fix for next time":
>>
>> Can you please make sure that the release artifacts start with the
>> official project name next time? e.g.
>>
>> apache-fluo-build-resources-1.0.0-incubating-source-release.tar.gz
>> apache-fluo-parent-1-incubating-source-release.tar.gz
>>
>> I assume this is easy to do (at least I know other projects have that
>> figured out).
>>
>> Christopher wrote:
>> > Fluo Developers,
>> >
>> > I'm combining these two votes, because they are a bit interdependent,
>> and
>> > both are small.
>> >
>> > Please consider the following candidates for Fluo Parent POM
>> 1-incubating
>> > and Fluo Build Resources 1.0.0-incubating.
>> >
>> > Git Commits/branches:
>> >  02d4ea2332598a94285985ee8a1c8e92a42b4770
>> (build-resources-1.0.0-rc1)
>> >  95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
>> >
>> > If this vote passes, a vote will be brought to the IPMC, and if that
>> > 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
>> >
>> > Staging repo:
>> > https://repository.apache.org/content/repositories/orgapachefluo-1004
>> >
>> > Source artifacts:
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1004/org/apache/fluo/build-resources/1.0.0-incubating/build-resources-1.0.0-incubating-source-release.ta

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

[Christopher]

You're looking in the wrong place. The address is:
https://dist.apache.org/repos/dist/dev/incubator/fluo (that's dist/dev/,
not dist/release/)
Also, that staging location is optional. I only put them there as a matter
of convenience for those preferring to download from there rather than
examine them in Nexus, and to make it easy to "release" with a simple "svn
mv" later.

The names for the tarballs were discussed in a previous thread on the
incubator list. The names are derived from the artifactId names in their
Maven coordinates. Modifying the tarballs to diverge from these doesn't
make sense, because they won't match the actual artifacts in Maven Central,
and that can cause a lot of confusion when users try to find the correct
artifact for dependency resolution. Further, adding "apache-" as a prefix
is redundant in the Maven coordinates because the groupId is
org.apache.fluo. The "apache-" prefix is not required, and is not done by
many Apache projects. Additionally, the build-resources artifact is
actually just "build-resources" it does not have "fluo" in the name,
because while the fluo parent POM uses it, and it is produced by the fluo
team, it does not actually have anything to do with "fluo" software. It
could be used by any project wishing to depend on the checkstyle/formatter
rules it contains.

So, yes, we could rename the artifactId so that "apache-" and
"apache-fluo-" prefix these artifacts... but I think it's not necessary,
adds redundancy to the maven coordinates, and doesn't actually seem to
achieve any useful goal. As far as I can tell, the only thing I can tell
that it actually accomplishes is make the file names ridiculously long.

Also, if we don't do that this time, but rename the artifacts later, then
we have the situation where you can't just update the version number to
update to the next version... users actually have to start changing which
artifact they are dependent on.

On Sun, Aug 7, 2016 at 9:12 PM Josh Elser <els...@apache.org> wrote:

> -1
>
> I do not see a published KEYS file for Fluo at
> https://dist.apache.org/repos/dist/release/incubator/fluo (you don't
> have the staging directory at all, actually). I am happy to switch this
> to +1 after this file is made (VOTE doesn't need to fail).
>
> The good:
>
> * sigs/xsums match
> * DISCLAIMER is present
> * Files have correct license headers
> * LICENSE and NOTICE are correct
>
> The "please fix for next time":
>
> Can you please make sure that the release artifacts start with the
> official project name next time? e.g.
>
> apache-fluo-build-resources-1.0.0-incubating-source-release.tar.gz
> apache-fluo-parent-1-incubating-source-release.tar.gz
>
> I assume this is easy to do (at least I know other projects have that
> figured out).
>
> Christopher wrote:
> > Fluo Developers,
> >
> > I'm combining these two votes, because they are a bit interdependent, and
> > both are small.
> >
> > Please consider the following candidates for Fluo Parent POM 1-incubating
> > and Fluo Build Resources 1.0.0-incubating.
> >
> > Git Commits/branches:
> >  02d4ea2332598a94285985ee8a1c8e92a42b4770 (build-resources-1.0.0-rc1)
> >  95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
> >
> > If this vote passes, a vote will be brought to the IPMC, and if that
> > 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
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachefluo-1004
> >
> > Source artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1004/org/apache/fluo/build-resources/1.0.0-incubating/build-resources-1.0.0-incubating-source-release.tar.gz
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1004/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 Sun Aug 07 21:00:00 UTC 2016
> > (Sun Aug 07 17:00:00 EDT 2016 / Sun Aug 07 14:00: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-1004/
> >  # note the trailing slash is needed
> >
>

Re: Where is fluo-parent?

[Christopher]

Ah okay.

On Sat, Aug 6, 2016, 13:19 Keith Turner <ke...@deenlo.com> wrote:

> On Sat, Aug 6, 2016 at 12:53 PM, Christopher <ctubb...@apache.org> wrote:
> > On Sat, Aug 6, 2016, 09:42 Keith Turner <ke...@deenlo.com> wrote:
> >
> >> Its in another branch, until we can get it released you will need to
> >> install it.  The parent depends on build resources which is another
> >> branch, need to install that also.  I would install the ones we are
> >> currently voting on for release in the branches below below.   Then
> >> change the the version of the parent Fluo's pom to 1-incubating.
> >>
> >> https://github.com/apache/incubator-fluo/tree/fluo-parent-1-rc3
> >> https://github.com/apache/incubator-fluo/tree/build-resources-1.0.0-rc1
> >>
> >> so do
> >>   git checkout fluo-parent-1-rc3; mvn install
> >>   git checkout build-resources-1.0.0-rc1; mvn install
> >>   then checkout master and change the parent version
> >>
> >> The reason I would use the rc versions at the moment is that the
> >> current versions have a small problem that the rc versions dont.
> >>
> >>
> > Oh? What small problem?
>
> The versions are misaligned in the branches between parent pom and
> resources pom.  The parent pom points to a non snapshot version of the
> resources.  The resources declares itself as a snapshot.  The RC
> branches do not have this problem.
>
>
> >
> >>
>

Re: Where is fluo-parent?

[Christopher]

On Sat, Aug 6, 2016, 09:42 Keith Turner  wrote:

> Its in another branch, until we can get it released you will need to
> install it.  The parent depends on build resources which is another
> branch, need to install that also.  I would install the ones we are
> currently voting on for release in the branches below below.   Then
> change the the version of the parent Fluo's pom to 1-incubating.
>
> https://github.com/apache/incubator-fluo/tree/fluo-parent-1-rc3
> https://github.com/apache/incubator-fluo/tree/build-resources-1.0.0-rc1
>
> so do
>   git checkout fluo-parent-1-rc3; mvn install
>   git checkout build-resources-1.0.0-rc1; mvn install
>   then checkout master and change the parent version
>
> The reason I would use the rc versions at the moment is that the
> current versions have a small problem that the rc versions dont.
>
>
Oh? What small problem?

>

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

[Christopher]

If it helps anybody, I also uploaded the release candidates to
https://dist.apache.org/repos/dist/dev/incubator/fluo/
These are the same artifacts (feel free to check), but they are staged in a
layout which some might be more comfortable with for evaluating staged
release candidates (particularly those in the IPMC unfamiliar with Maven
staging repos).

This will also make it easier to actually perform the release once they are
approved by the IPMC, because it will be simple to just "svn mv" them over
to the release area to get picked up by the mirrors.

On Fri, Aug 5, 2016 at 6:31 PM Christopher <ctubb...@apache.org> wrote:

> +1
>
> * Verified sha1, md5, and gpg signatures for all artifacts in staging repo
> * Verified build-resources jar is accompanied by javadoc and sources jars
> * Verified LICENSE/NOTICE in all built jars
> * Verified source tarballs contain Incubator DISCLAIMER file and
> LICENSE/NOTICE files
> * Verified build-resources source jar files match same files in git commit
> * Verified both pom files in repo match corresponding pom.xml in their
> respective git commits
> * Verified both source-release tarballs match their corresponding git
> commit
> * Verified Fluo could build with the parent pom, and executed the
> formatter and checkstyle rules in the build-resources, as specified by the
> parent POM
>
> On Fri, Aug 5, 2016 at 4:02 PM Mike Walch <mwa...@gmail.com> wrote:
>
>> +1
>>
>> * Verified sha1 & md5 hashes for fluo-parent & build-resoures
>> * Verified signatures for fluo-parent & build-resources
>> * Built Fluo and Fluo recipes using staging repo and new fluo-parent
>>
>> On Fri, Aug 5, 2016 at 11:11 AM Keith Turner <ke...@deenlo.com> wrote:
>>
>> > +1
>> >
>> >  * sigs and hashes are good on parent pom and resources jar
>> >  * able to build Fluo and Fluo Recipes using staging repo and parent
>> > pom version 1-incubating
>> >  * Resources eclipse-formatter.xml and java-checkstyle.xml in jar are
>> > same as files in rc1 branch
>> >  * Parent pom in staging repo is same as parent pom in rc3 branch
>> >
>> > On Thu, Aug 4, 2016 at 4:48 PM, Christopher <ctubb...@apache.org>
>> wrote:
>> > > Fluo Developers,
>> > >
>> > > I'm combining these two votes, because they are a bit interdependent,
>> and
>> > > both are small.
>> > >
>> > > Please consider the following candidates for Fluo Parent POM
>> 1-incubating
>> > > and Fluo Build Resources 1.0.0-incubating.
>> > >
>> > > Git Commits/branches:
>> > > 02d4ea2332598a94285985ee8a1c8e92a42b4770
>> (build-resources-1.0.0-rc1)
>> > > 95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
>> > >
>> > > If this vote passes, a vote will be brought to the IPMC, and if that
>> > > 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
>> > >
>> > > Staging repo:
>> > > https://repository.apache.org/content/repositories/orgapachefluo-1004
>> > >
>> > > Source artifacts:
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1004/org/apache/fluo/build-resources/1.0.0-incubating/build-resources-1.0.0-incubating-source-release.tar.gz
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachefluo-1004/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 Sun Aug 07 21:00:00 UTC 2016
>> > > (Sun Aug 07 17:00:00 EDT 2016 / Sun Aug 07 14:00: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-1004/
>> > > # note the trailing slash is needed
>> >
>>
>

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

[Christopher]

+1

* Verified sha1, md5, and gpg signatures for all artifacts in staging repo
* Verified build-resources jar is accompanied by javadoc and sources jars
* Verified LICENSE/NOTICE in all built jars
* Verified source tarballs contain Incubator DISCLAIMER file and
LICENSE/NOTICE files
* Verified build-resources source jar files match same files in git commit
* Verified both pom files in repo match corresponding pom.xml in their
respective git commits
* Verified both source-release tarballs match their corresponding git commit
* Verified Fluo could build with the parent pom, and executed the formatter
and checkstyle rules in the build-resources, as specified by the parent POM

On Fri, Aug 5, 2016 at 4:02 PM Mike Walch <mwa...@gmail.com> wrote:

> +1
>
> * Verified sha1 & md5 hashes for fluo-parent & build-resoures
> * Verified signatures for fluo-parent & build-resources
> * Built Fluo and Fluo recipes using staging repo and new fluo-parent
>
> On Fri, Aug 5, 2016 at 11:11 AM Keith Turner <ke...@deenlo.com> wrote:
>
> > +1
> >
> >  * sigs and hashes are good on parent pom and resources jar
> >  * able to build Fluo and Fluo Recipes using staging repo and parent
> > pom version 1-incubating
> >  * Resources eclipse-formatter.xml and java-checkstyle.xml in jar are
> > same as files in rc1 branch
> >  * Parent pom in staging repo is same as parent pom in rc3 branch
> >
> > On Thu, Aug 4, 2016 at 4:48 PM, Christopher <ctubb...@apache.org> wrote:
> > > Fluo Developers,
> > >
> > > I'm combining these two votes, because they are a bit interdependent,
> and
> > > both are small.
> > >
> > > Please consider the following candidates for Fluo Parent POM
> 1-incubating
> > > and Fluo Build Resources 1.0.0-incubating.
> > >
> > > Git Commits/branches:
> > > 02d4ea2332598a94285985ee8a1c8e92a42b4770
> (build-resources-1.0.0-rc1)
> > > 95c48e3f14faf5cdca259d8ec60ec68b640fce1e (fluo-parent-1-rc3)
> > >
> > > If this vote passes, a vote will be brought to the IPMC, and if that
> > > 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
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapachefluo-1004
> > >
> > > Source artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1004/org/apache/fluo/build-resources/1.0.0-incubating/build-resources-1.0.0-incubating-source-release.tar.gz
> > >
> >
> https://repository.apache.org/content/repositories/orgapachefluo-1004/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 Sun Aug 07 21:00:00 UTC 2016
> > > (Sun Aug 07 17:00:00 EDT 2016 / Sun Aug 07 14:00: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-1004/
> > > # note the trailing slash is needed
> >
>

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

[Christopher]

+1

Built Fluo using pom
(Double-)checked signatures and hashes
Verified tarball matches git branch for rc2 (aside from the previously
noted and expected DEPENDENCIES file)
Checked LICENSE, NOTICE, and DISCLAIMER files
Verified maven fluo-parent-1-incubating.pom artifact matches pom.xml from
tarball and git branch.
Double checked the sha1 on the git branch matches what's in this email.


On Thu, Jul 28, 2016 at 10:15 AM Keith Turner <ke...@deenlo.com> wrote:

> +1
>
> Was able to build Fluo using pom
> Sig and hash of pom is good
> Pom in staging repo is identical to one in branch
>
> On Wed, Jul 27, 2016 at 1:13 PM, Christopher <ctubb...@apache.org> wrote:
> > Fluo Developers,
> >
> > Please consider the following candidate for Fluo Parent POM 1-incubating.
> >
> > Git Commit:
> > e9ed4334dd4cc5df27def417f26d6d7362470cb8
> > Branch:
> > fluo-parent-1-rc1
> >
> > If this vote passes, a vote will be brought to the IPMC, and if that
> > 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 Sat Jul 30 18:00:00 UTC 2016
> > (Sat Jul 30 14:00:00 EDT 2016 / Sat Jul 30 11:00: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: Notifications list

[Christopher]

Oh, hmm.

On Thu, Jul 7, 2016 at 2:40 PM Josh Elser <josh.el...@gmail.com> wrote:

> Really? I've been getting them.
>
> Christopher wrote:
> > Right now, they don't appear to be going anywhere.
> >
> > On Thu, Jul 7, 2016 at 2:18 PM Josh Elser<josh.el...@gmail.com>  wrote:
> >
> >> By default, they go to the dev list. I believe we can ask for them to be
> >> sent to notifications if we so desire.
> >>
> >> Christopher wrote:
> >>> After thinking about it, even though I'd have expected things to go to
> >> the
> >>> dev list, I'd prefer they go to notifications.
> >>>
> >>> On Thu, Jul 7, 2016 at 11:30 AM Christopher<ctubb...@apache.org>
>  wrote:
> >>>
> >>>> I'd expect them to go to the dev list. Perhaps that part of Fluo's
> >> GItHub
> >>>> integration was never set up?
> >>>>
> >>>> On Thu, Jul 7, 2016 at 10:09 AM Keith Turner<ke...@deenlo.com>
>  wrote:
> >>>>
> >>>>> Should Github issues and pull request be going to the notifications
> >> lists?
> >
>

Podling name search

[Christopher]

I've created a JIRA, beginning the task of establishing the Fluo name's
suitability as an Apache trademark:
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-109

This is a task required prior to graduation, but I figured it's never too
early to start.

Documentation about what we need to do is here:
http://incubator.apache.org/guides/names.html#search

Re: Notifications list

[Christopher]

I'd expect them to go to the dev list. Perhaps that part of Fluo's GItHub
integration was never set up?

On Thu, Jul 7, 2016 at 10:09 AM Keith Turner  wrote:

> Should Github issues and pull request be going to the notifications lists?
>

Re: [DISCUSS] Require Java 8

[Christopher]

On Thu, Jul 7, 2016 at 9:21 AM Keith Turner <ke...@deenlo.com> wrote:

> +0
>
> I am not strongly in favor, but I am not opposed.  My thoughts are :
>
>  * Nothing in 1.0.0 implementation or API will actually require Java 8.
> Ideally the switch would have been made earlier.  Switching at the
> beginning of the 1.1.0 dev cycle makes more sense to me.
>

I just don't think we should be encouraging new users of a new application
to use EOL software. Also, if there is a problem with compatibility, I'd
prefer the problem occur while trying to backport Fluo to Java 7, if
somebody were to require that, than the problem occur while trying to use a
current non-EOL version.


>  * Users on Java 7 will not be able to use Fluo
>

I'm okay with that. They should upgrade if they want Fluo.


>  * Fluo Recipes is already at Java 8 and its implementation heavily uses
> it.
>
> How will it simplify pom?
>
>
Specifically, it will eliminate the need to have a separate JDK8 profile
for Java 8 javadoc behaviors. It would also allow us to set the compiler
plugin properties at the parent POM level, instead of in each POM.

These are only slight improvements.


> On Tue, Jul 5, 2016 at 4:11 PM, Christopher <ctubb...@apache.org> wrote:
>
> > What do folks think about making all of Fluo require Java 8 as a minimum
> > before the 1.0.0 release? I think it's a good idea. It'll help with API
> > modifications over time, and it will simplify some parts of the parent
> POM.
> >
>

Re: What's next?

[Christopher]

Looks like Mike created https://issues.apache.org/jira/browse/INFRA-12164 for
the incubator-fluo-website mirror.

On Wed, Jun 22, 2016 at 4:06 PM Christopher <ctubb...@apache.org> wrote:

> Could add the git repo for the website (incubator-fluo-website.git). Not
> sure why, but it's not showing up on https://git.apache.org/, and I don't
> think anybody has requested GitHub mirroring/issues for it yet.
>
> On Tue, Jun 21, 2016 at 6:14 PM Josh Elser <josh.el...@gmail.com> wrote:
>
>> Also, just adding the commits@ list and corrected the reference to JIRA
>> for the issue tracker.
>>
>> Josh Elser wrote:
>> > Just updated http://incubator.apache.org/projects/fluo.html with the
>> > latest (getting infra transferred over to the ASF).
>> >
>> > What's the next big things to do? It looks like the website is already
>> > up (great!), although the ASF incubator disclaimer is still missing.
>> > Mike, you might already be working on this -- a PR from you is ringing a
>> > bell...
>> >
>> > Is a release the next big thing to try to tackle? Going through the
>> > name-search process is also a good one to get out of the way early
>> > (avoid a potential project rename right before you graduate).
>> >
>> > Mentors: as per one of the boxes I checked,
>> > http://incubator.apache.org/projects/fluo.html is the thing to tracke
>> as
>> > the podling progresses. Now we're all aware :)
>> >
>> > - Josh
>>
>

Re: What's next?

[Christopher]

Could add the git repo for the website (incubator-fluo-website.git). Not
sure why, but it's not showing up on https://git.apache.org/, and I don't
think anybody has requested GitHub mirroring/issues for it yet.

On Tue, Jun 21, 2016 at 6:14 PM Josh Elser  wrote:

> Also, just adding the commits@ list and corrected the reference to JIRA
> for the issue tracker.
>
> Josh Elser wrote:
> > Just updated http://incubator.apache.org/projects/fluo.html with the
> > latest (getting infra transferred over to the ASF).
> >
> > What's the next big things to do? It looks like the website is already
> > up (great!), although the ASF incubator disclaimer is still missing.
> > Mike, you might already be working on this -- a PR from you is ringing a
> > bell...
> >
> > Is a release the next big thing to try to tackle? Going through the
> > name-search process is also a good one to get out of the way early
> > (avoid a potential project rename right before you graduate).
> >
> > Mentors: as per one of the boxes I checked,
> > http://incubator.apache.org/projects/fluo.html is the thing to tracke as
> > the podling progresses. Now we're all aware :)
> >
> > - Josh
>

Re: Contribute in Fluo

[Christopher]

Hi Garvit,

Sure. We're just getting set up transitioning to the Apache Incubator.
We're using GitHub issues to track bugs/features:
https://github.com/apache/incubator-fluo/issues and the current workflow is
to submit pull requests for feature changes.

We're still working on setting up the website (https://fluo.apache.org/),
so if you have any suggestions there, that would be helpful, too.

On Tue, Jun 21, 2016 at 2:20 PM Garvit Bansal 
wrote:

> Hi All,
>
> My name is Garvit and I like to contribute in Fluo. I found this project
> interesting and want to make contribution to it. Can somebody help me how
> to start with, bug fixes or something like that which will help me to get
> in flow.
>
> Garvit
> --
> *Garvit Bansal,*
> Software Developer at Flipkart
> B.Tech in Computer Science and Engineering
> The LNM Institute of Information Technology
> Jaipur, Rajasthan-302001
> *Mobile:* 9610728532, 9886384276
> *Website:* garvitbansal244.appspot.com
>
> 
>

Re: Incoming commits@ list

[Christopher]

Works for me.

On Thu, Jun 16, 2016 at 2:19 PM Josh Elser  wrote:

> Infra gently suggested that we have a commits@ list for consistency with
> other projects.
>
> I just submitted the form to create it and will send a note when it's made.
>

Re: GH repo transfer next step

[Christopher]

Done.

On Thu, Jun 16, 2016 at 1:00 PM Josh Elser <josh.el...@gmail.com> wrote:

> All,
>
> I just talked to INFRA in HipChat to see what we're waiting on regarding
> the latest decision (use GH issues and transfer the repos to the apache
> "org").
>
> The instructions I received were:
>
> "Add pono as an owner to the org that holds the repos then he can handle
> the txfr".
>
> Christopher/Mike/Keith, can one of you do the above, please?
>
> - Josh
>