This vote will remain open for 72 hours (3 days), until Tue, 2014 April 28 01:00 UTC. (That's 9pm EDT on Monday.)
[ ] +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.6.0 release of Apache Accumulo.
Do you think doing this on a Friday was a good idea? I know that point came up earlier, and it was possibly due to already discovered issues that would fail the release, but I think the lack of traffic on here is significant. On Fri, Apr 25, 2014 at 8:37 PM, Christopher <[EMAIL PROTECTED]> wrote:
I think Friday was fine. I know I've just been silent due to recovery time from the surge of activity around making sure RC4 would be ready. I suspect it might be the same for others. On Mon, Apr 28, 2014 at 7:24 AM, William Slacum < [EMAIL PROTECTED]> wrote: Sean
We also have a tendency to vote at the last minute anyway, regardless of weekend or weekday. I hope that's because everybody is busy running tests. On Mon, Apr 28, 2014 at 11:04 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:
I don't know what everyone's schedules are. If the point of a vote was to begin performing testing, I'd say yes, or if this were RC1, I'd say yes (or extended it to 4 days so it's not a surprise). However, since we're already in the RC mindset, having had 3 prior ones already, an RC4 was already expected to be forthcoming. Since I don't think any of the issues since RC3 invalidate the previous testing, and because this is RC4, having gone through several previous candidates, I think a 3 day vote starting on Friday is fine. That gives many people an opportunity to examine the release candidate's changes since the last one, whether they do so on a weekend or whether they do so on Monday.
I'm not concerned about the lack of initial activity... that's usually the pattern for votes.
Do you think you need extra time to evaluate the release candidate? Do we need to discuss an extension?
I was concerned about the lack of activity. I don't have a personal need for an extension, but I do recall a discussion about Friday RC's potentially being problematic in the past, which is why I brought it up. On Mon, Apr 28, 2014 at 11:21 AM, Christopher <[EMAIL PROTECTED]> wrote:
Please change the subject if you're going to change this into a conversation about when to start votes. This subject is for votes for an RC candidate. On Mon, Apr 28, 2014 at 11:30 AM, William Slacum < [EMAIL PROTECTED]> wrote:
* Verified all signatures and checksums. * Ran continuous ingest with binary artifact + custom built native maps. The issues, but not enough to vote against:
* Encountered ACCUMULO-2741. * Encountered ACCUMULO-2742. * Source artifact missing .gitignore ** This has been discussed, and I'm voting for precedent here. We can agree to disagree, and if this vote passes then a new precedent will have been set. The bad:
* CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD) ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav ** It seems like we agreed to only include changes from the current major release line, but that is not 100% clear.
On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
My understanding from that prior conversation is that, with the way we use JIRA to mark things as fixed in the latest major release and enumerating the fix versions to denote all the bugfix releases in which it was fixed, meant that we can cover the entire CHANGE history (after a certain point) by including only the major releases, and the bugfixes since the last major one. Therefore, since this is a major release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed in 1.5.1 would also be marked as fixed for 1.6.0 (if it still applied), so the 1.6.0 changes include those and 1.5.1 is not needed to list separately. This was not done for 1.5.0, because we hadn't discussed it then.
It seems you came to a different understanding from that conversation. If I understand you correctly, it would mean we should only include 1.6.0 changes? If that's the case, do you think a -1 is warranted for including more than necessary (1.4.0 and 1.5.0)? The rat check plugin typically ignores README/NOTICE/LICENSE files as category "N" (for Notices). That's why it ignored the japi-compliance/README and conf/examples/crypto/readme.txt. I think it's expected that the LICENSE file covers them. At the very least, I don't think they contain anything copyrightable that would necessitate a license. But, for consistency, maybe we should add it anyway? I'm not sure that consistency argument warrants blockage (for me), though.
The rest were ignored because the rat check does not check binary files. These files should be covered by the LICENSE/NOTICE files. Binary document files may or may not be capable of supporting license metadata, in general, but I think the coverage by the LICENSE/NOTICE files is sufficient. However, we can do additional things with these files. The ScaleTest.odp could probably be converted to markdown, with a license header. The state_diagrams are not used anywhere in the LaTeX generation (leftover from old developer manual?), and could probably be deleted or moved to the website or wiki, if they are needed at all. I'm not sure which option is best. However, again, I'd consider the LICENSE/NOTICE files sufficient, so as not to block, especially since they didn't block any previous release (presumably because LICENSE/NOTICE covered them), and they've been around awhile.
With the spate of blockers uncovered during the rc process so far , I'm uncomfortable approving the release so quickly after the most recent one was resolved. It's true there was a measure of luck in these being found when they were, but they appear to be indications that the code hasn't been up to snuff until very recently. My vote means "I'd rather wait some short amount of time to be sure".
*However*, 1.6.0 really does need to be released, so I'm not willing to go all the way with -1. A blocker could come in the day after the eventual passing rc, no matter how long we might wait.
In case of passage, tests I've run on rc4 so far: unit tests pass, functional tests pass, randomwalk ShortEach passes; randomwalk LongEach in progress. (randomwalk on 7-node cluster, 2 masters, 5 tservers, 3 zk, CDH 4.5)
I am seeing consistently slower write rates when comparing 1.5.1 and 1.6.0. Following env :
* hadoop 2.2.0 * Zookeeper 3.4.5 * Centos 6 (native, not a VM) * using examples/3GB/native-standalone config * setting tserver.mutation.queue.max 4M * I am running test/system/test1/ingest_test.sh * single node
* Signatures and hashes validated. * Source artifact matches given commit, modulo previously mentioned .gitignore file. * I agree that previous tests needn't be invalidated by changes introduced in this RC * Did one last run through the ITs with each of the hadoop profiles * I am aware of concerns about ACCUMULO-2745 and the recent run of last minute blockers.
On Fri, Apr 25, 2014 at 7:35 PM, Christopher <[EMAIL PROTECTED]> wrote: Sean
There was a discussion about CHANGES. I am not sure there could truly be consensus w/o a vote on that particular subject. I don't think its something that should hold up 1.6.0 On Mon, Apr 28, 2014 at 5:19 PM, Christopher <[EMAIL PROTECTED]> wrote:
-1 because of issue w/ license files. Opened ACCUMULO-2749. I am not sure this should hold up 1.6.0 unless we can figure out what the problem is in short order. On Fri, Apr 25, 2014 at 8:35 PM, Christopher <[EMAIL PROTECTED]> wrote:
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext