Good point, Christopher. I didn't really consider projects outside of
the Hadoop ecosystem. As long as we're cognizant (if our versioning
strings do get "better" moving forward), I think this shouldn't be an
issue. Hold me honest :)
Christopher wrote:
Another point to consider here is that ma
Another point to consider here is that many projects (such as guava) omit
".0" suffixes on versions (releasing, for instance 11, followed by 11.0.1
and 11.0.2 for bugfixes).
It's probably not a big deal. It's only a slight risk of confusion, and SCM
is not for users, it's for devs, so I'm fine wit
This is easily resolved if we're limiting fixes on these branches to
bugfixes, and not backporting features. If a fix makes it in the branch
before a RC, there's no reason it can't be evaluated for release, I'd
think. In these bugfix branches, we typically haven't had decisions about
whether to inc
Well, color me shocked -- the verify found some bad data. It looks
like two keys have bad checksums (which I assume is what created the
UNDEFINEDs, too?).
CORRUPT 2
REFERENCED 219908
UNDEFINED 2
UNREFERENCED 874770
I ran two tabletservers on my desktop, turned on hflush instead of
hsync, swit
Github user ctubbsii commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/16#discussion_r17931845
--- Diff:
core/src/main/java/org/apache/accumulo/core/client/admin/TableOperations.java
---
@@ -103,6 +103,25 @@
void create(String tableName, boole
Github user ctubbsii commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/16#discussion_r17931715
--- Diff:
core/src/main/java/org/apache/accumulo/core/client/admin/TableOperations.java
---
@@ -103,6 +103,25 @@
void create(String tableName, boole
+1
* Verified checksums+sigs
* Build from source tarball and ran all unit+functional tests against
Apache Hadoop 2.5.1 and 2.6.0-SNAPSHOT
* Ingested 2B records w/ CI + clean verify with single tserver (Apache
Hadoop 2.6.0-SNAPSHOT + Apache ZooKeeper 3.4.5)
* Ingested ~2.5B records w/ CI with 2 tse
GitHub user hustjl22 opened a pull request:
https://github.com/apache/accumulo/pull/16
ACCUMULO-3089: Create volume chooser from table properties
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/hustjl22/accumulo ACCUMULO-3089
Al
I'm fine with the release manager selecting the branching strategy for a
release. A benefit to having a release branch is that it makes merges from
upstream after the branch is established explicit, so it's much less likely
any undesirable commit will sneak in (i.e., escape the notice of the
releas
On Tue, Sep 23, 2014 at 11:45 AM, Josh Elser wrote:
> Personally, I like the succinctness of "1.5" over the ones you
> presented. I don't feel like "1.5.x" or "1.5-dev" tell me anything
> more than "1.5" already did so they just turn into more typing. I
> don't really think there's a high chance
Personally, I like the succinctness of "1.5" over the ones you
presented. I don't feel like "1.5.x" or "1.5-dev" tell me anything
more than "1.5" already did so they just turn into more typing. I
don't really think there's a high chance that we ever abandon x.y.z
version strings, so there isn't a b
There are two cases I see here (RCx failed, and you want to RCx+1):
there were changes upstream and we want to include them all in the
next release candidate or there were changes upstream and we only want
some of them in the release candidate.
I highly anticipate the former to be the common case
+1
I also like Dave's suggestion of branching just in time for a release to
keep work on it isolated. That would be an appropriate action to take at
feature freeze.
On Tue, Sep 23, 2014 at 9:23 AM, Corey Nolet wrote:
> +1
>
> Using separate branches in this manner just adds complexity. I was
>
>
> (which needs to be signed)
>
It is signed... I forgot I have to add trust:
$ gpg --update-trustdb
Thanks Corey!
On Tue, Sep 23, 2014 at 9:19 AM, Eric Newton wrote:
> +1
> Verified signature (which needs to be signed)
> Verified ingest performance (on a single node)
> Looked over the user
+1
Using separate branches in this manner just adds complexity. I was
wondering myself why we needed to create separate branches when all we're
doing is tagging/deleting the already released ones. The only difference
between where one leaves off and another begins is the name of the branch.
On
If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch, then do
you run the risk of someone committing something destined for 1.6.2 being
captured in a 1.6.1-RC2 tag? Do you want to prevent that? If so, how?
On my project we use a long running development branch, but when we ar
+1
Verified signature (which needs to be signed)
Verified ingest performance (on a single node)
Looked over the user's manual from the binary tarball
Ran all unit and integration tests
On Fri, Sep 19, 2014 at 10:49 PM, Corey Nolet wrote:
> Devs,
>
> Please consider the following candidate for A
+1 to static dev branch names per release series. (this would also fix the
Jenkins spam when the builds break due to branch name changes)
However, I kind of prefer 1.5.x or 1.5-dev, or similar, over simply 1.5,
which looks so much like a release version that I wouldn't want it to
generate any conf
+1 on having branches named for major release lines instead of specific
versions.
On Mon, Sep 22, 2014 at 8:18 PM, Josh Elser wrote:
> After working on 1.5.2 and today's branch snafu, I think I've come to the
> conclusion that our branch naming is more pain than it's worth (I believe I
> was the
+1
On Mon, Sep 22, 2014 at 10:18 PM, Josh Elser wrote:
> After working on 1.5.2 and today's branch snafu, I think I've come to the
> conclusion that our branch naming is more pain than it's worth (I believe I
> was the one who primarily argued for branch names as they are current
> implemented,
20 matches
Mail list logo
