accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: 1.6.0 Feature Freeze
Date Thu, 31 Oct 2013 20:39:22 GMT
On Thu, Oct 31, 2013 at 1:35 PM, John Vines <> wrote:

> >
> So I am interpreting it as all code modifications must be into the codebase
> or review board by the freeze date. Which could be beneifical, however-
> 1. What about the case where a patch needs to be modified? What if it's a
> really minor change vs. a major change? Where's the line?

That's up to the release manager, though they can ask the community for
feedback. :)

Generally, I think this is a non-issue. review board lets you post updates
to your patch. If it didn't, feedback would be useless. I don't think we're
saying you can't update your review board.

So I think it comes down to the feedback itself. if it suggests a change
that you can incorporate into the existing patch, good to go. if it's
requires a rewrite, then it sounds more like a -1 and goes to the
removal-vote process.

> 2. In the case of features that have multiple subtasks, they have
> complementing features that  NEED to exist to make the main feature
> usable/maintainable. What happens if we don't get those in?

That's why we have a call-to-remove part of the vote, right? committer
votes will determine if a given feature has retained enough to be included.

This is also a big advantage of review-then-commit and iterating within the
ticket before pushing up. You can have these kind of inclusion
conversations at a much lower cost when you aren't facing the prospect of
trudging through a bunch of reverts.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message