Note that I added another build so that we could continue to have CI for
the "optional" components [1]. This build only does "mvn clean package"
and does not deploy the artifacts.
--Aaron
[1]
https://builds.apache.org/view/All/job/incubator-rya-master-with-optionals/
On Wed, Oct 12, 2016 at 2:
Thanks Josh. I was satisfied with Puja's commits as well, so I'm going to
pull those into master, create a new JIRA task for the dependencies that
you mentioned, and add those to RYA-184.
On Wed, Oct 12, 2016 at 2:34 PM Josh Elser wrote:
> Thanks for putting this together, Puja. I don't see t
Thanks for putting this together, Puja. I don't see the geotools related
issues anymore.
I took a glance at another JAR that a `mvn package` creates this time:
extras/indexing/target/rya.indexing-3.2.10-SNAPSHOT-accumulo-server.jar
In here, I found: hep/aida/bin/AbstractBin.class
Per https://
I'm tracking everything in JIRA and that's the primary source. This
spreadsheet is really just a view on RYA-184 in JIRA.
On Wed, Oct 12, 2016 at 1:48 PM Josh Elser wrote:
> Uh.. why not just use JIRA?
>
> fixVersion, status=Blocker, and Assignees are there for a reason...
>
> Aaron D. Mihalik
Uh.. why not just use JIRA?
fixVersion, status=Blocker, and Assignees are there for a reason...
Aaron D. Mihalik wrote:
All,
I'm maintaining a small spreadsheet of issues [1] we need to resolve for
RC2. It is essentially a finer grained copy of what we have in Jira at
RYA-184 [2] (in order to
All,
I'm maintaining a small spreadsheet of issues [1] we need to resolve for
RC2. It is essentially a finer grained copy of what we have in Jira at
RYA-184 [2] (in order to keep track of merges and whatnot).
If anyone is interested in working on RC2, check RYA-184 or this
spreadsheet for an ope
The only breaking change that I think we have had this far has been the
artifacts moving to an Apache namespace. I probably would have voted against
doing that too.
I guess more importantly, I'd like us to get out a release soon rather than
keep adding more features in. Theoretically the next
FYI: There are already a handful of package name changes and other breaking
refactoring from 3.2.9 to 3.2.10. This would be along those lines and not
present any significant API changes.
On Wed, Oct 12, 2016 at 8:30 AM Puja Valiyil wrote:
> -1 I think we should wait. I'd like us to have one no
-1 I think we should wait. I'd like us to have one non-breaking official
release on Apache before we start adding changes that will greatly effect end
users. Dramatically changing the Api seems like a bad idea since users will
have no choice but to update.
Theoretically once we get past the f
+1 fix it before the next RC
We'll inconvenience some users now, but I'd rather fix it now, before the
pool of users grows much larger.
The issue being that we have a number pull request outstanding, and it
would break those pull requests. So we're somewhat inconveniencing
ourselves.
We had some
10 matches
Mail list logo
