On 6/23/14, 3:31 PM, Sean Busbey wrote:
I realize we're past window here, but a few things:
It's ok. I only remembered about this early today.
1) I'm concerned about changing our testing standards prior to getting some
practice in on holding to tighter bounds on what can go into a particular
kind of fix number. However, I generally like the idea of just relying on
people voting -1 for insufficient testing.
2) We really could have used a [VOTE] on changing 1.x versions to use
bugfix for the last number. It would be an opportunity to formally adopt
our release governance docs into the PMC bylaws by reference.
I don't see this as a huge issue since everyone seemed to be in
agreement on it. Writing it down for reference would be good for future
discussions on the subject.
3) As a point of principle, David's veto was completely valid as it stood.
While we are individuals it's perfectly reasonable for the PMC to set
requirements on what goes into a release we sign off on, even if the PMC
members may not always have ready access to the resources needed to meet
that standard.
There's no reason David should have to volunteer resources to back up his
veto, especially when it was merely calling for a continuation of the
standard we already had set.
That's why I said "Unless you are willing to supply the funds to pay to
use some resources, I don't feel like this is a valid -1." If he, or
anyone, is willing provide general resources for testing, that's a
different story. Given his response, I assume that is not the case.
4) While I'm not in a position to obligate Cloudera, the team I'm on
currently has been allocated sufficient resources to meet the current
testing standards for a release and I have no reason to believe we won't
have said resources when future release windows happen.
This would require time from you, Mike or Bill H, yes? While having some
dedicated resources is nice, I'm worried about relying on other people
(who have their own obligations) to fulfill the release manager's
obligations.
I think that gets into the details which the release manager can
coordinate and other devs can express their concerns via the normal
release voting process.
-Sean
On Thu, Jun 19, 2014 at 3:03 PM, David Medinets <[email protected]>
wrote:
+0 I'm changing my vote after some reconsideration. Having the ability
to vote -1 on a release as Keith mentioned is good enough for a
bug-fix release.
On Thu, Jun 19, 2014 at 3:20 PM, David Medinets
<[email protected]> wrote:
-1 I hesitate to step into this discussion because I can't also step
up and do the long-term testing even as I recommend that it must be
done. There are at least four companies supporting Accumulo and
contributing back to the project. Surely one of those companies can
supply the resources to continue the existing test regimen? Is there
some concern that those resources won't be available for the next
release cycle?
On Thu, Jun 19, 2014 at 3:13 PM, Josh Elser <[email protected]>
wrote:
As we're starting to consider 1.5.2 and 1.6.1 coming out in the near
future,
I want to revisit a discussion[1] I started at the end of April
regarding
the "testing burden" that is currently set forth in our release
document[2].
What I'm proposing is to modify the language of the release document to
be
explicit about the amount of testing needed. For bug-fix, "minor"
releases
(e.g. 1.5.2 and 1.6.1), the 7 days of testing using continuous ingest
and
randomwalk (with and without agitation) will be clearly defined as "may"
instead of "should" or "must" language. If the resources are available,
it
is recommended that some longer, multi-process/node test is run against
the
release candidate; however, it is not required and should not prevent us
from making the minor release.
I will also include language that strongly recommends that the changes
included in the "minor" release be vetted/reviewed as a way to mitigate
the
risk of shipping new regressions.
I am not recommending that the language be changed for "major" releases
(e.g. 1.7.0 and 2.0.0) as these releases still imply significant new
features or internal changes.
Unless someone informs me otherwise, I will treat this as a normal
lazy-consensus approval. Assuming we move closer to "proper" semantic
versioning for 2.0.0, I believe these updated guidelines will change
again.
I do however think there is merit in making this change now so that we
can
get the good bugs that we've fixed out to our users.
Let me know what you think. I will wait, at least, the prescribed three
days
before changing any thing.
- Josh
[1]
http://mail-archives.apache.org/mod_mbox/accumulo-dev/201404.mbox/%3C535931A7.30605%40gmail.com%3E
[2] http://accumulo.apache.org/governance/releasing.html
