Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> 1.6.0 Feature Freeze


Copy link to this message
-
Re: 1.6.0 Feature Freeze
On Thu, Oct 31, 2013 at 4:39 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 31, 2013 at 1:35 PM, John Vines <[EMAIL PROTECTED]> 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.
>
> --
> Sean
>
All of your comments make sense to me. Unfortunately we're a bit stuck in
the latter category. Going forward we can make steps as a community to help
prevent it, but that doesn't change this release. And beside issue of
pulling out an incrementally committed feature, pulling out features lends
the potential for a release to be insubstantial.

So for the sake of the 1.6.0 release, what do we think we should do about
the sub-tasks for added/expected features? Particularly ones deemed
requisite for that feature to hit the mainline?
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB