On Fri, Jul 17, 2015 at 6:04 AM, Steve Loughran ste...@hortonworks.com
wrote:
On 16 Jul 2015, at 15:56, Karthik Kambatla ka...@cloudera.com wrote:
On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey bus...@cloudera.com
wrote:
On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla
On 16 Jul 2015, at 15:56, Karthik Kambatla ka...@cloudera.com wrote:
On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey bus...@cloudera.com wrote:
On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla ka...@cloudera.com
wrote:
On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran
+1 for steve's suggestion.
I agree completely that everything should be finalized before committing in.
-Vinay
On Jul 16, 2015 2:29 PM, Steve Loughran ste...@hortonworks.com wrote:
1. I agree that the bar for patches going in should be very high: there's
always the risk of some subtle
1. I agree that the bar for patches going in should be very high: there's
always the risk of some subtle regression. The more patches, the higher the
risk, the more traumatic the update
2. I like the idea of having a list of proposed candidate patches, all of which
can be reviewed and
On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran ste...@hortonworks.com
wrote:
1. I agree that the bar for patches going in should be very high: there's
always the risk of some subtle regression. The more patches, the higher the
risk, the more traumatic the update
2. I like the idea of
On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla ka...@cloudera.com
wrote:
On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran ste...@hortonworks.com
wrote:
-any change to the signature of an API, including exception types text
-changes to wire formats
These two should hold for minor
On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey bus...@cloudera.com wrote:
On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla ka...@cloudera.com
wrote:
On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran ste...@hortonworks.com
wrote:
-any change to the signature of an API, including
To close the loop on this one, I created a label for the candidate list of
patches:
https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.6.1-candidatehttps://issues.apache.org/jira/issues/?jql=labels%20=%202.6.1-candidate,
in order to make progress while the issue is still hot.
The
Inline
On Wed, Jul 15, 2015 at 5:22 PM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
I can understand these (sort of newish) questions from hbase-dev. We
already have a well laid-out release-management process. If people want to
learn more about how it works, please head over to
Why not just have the discussion here? It seems integral to the matter of
having more maintenance releases on those versions.
On Wed, Jul 15, 2015 at 11:39 AM, Karthik Kambatla ka...@cloudera.com
wrote:
I believe there was general consensus to do more maintenance releases, as
witnessed in the
Yeah, I started a thread while back on this one
(http://markmail.org/message/sbykjn5xgnksh6wg) and had many offline discussions
re 2.6.1.
The biggest problem I found offline was about what bug-fixes are acceptable and
what aren’t for everyone wishing to consume 2.6.1. Given the number of
Over on HBase, committers volunteer to be release runners for a whole
release line. I wouldn't use the word 'appoint' necessarily because the
arrangement is an informal communal practice, not written down anywhere as
policy or codified into bylaws.
If it is helpful to have a data point from
Is there anyone interested in volunteering to run a 2.6.1 release (Akira?)?
You'd get some help (especially if the bar is set high and only critical
bug fixes are allowed in: i.e. no features, no 'perf' fixes, no jar
updates, and so on).
St.Ack
On Wed, Jul 15, 2015 at 3:07 PM, Chris Douglas
As I proposed in the other thread, how about we adopting the following
model:
x.y.1 releases have all Blocker, Critical, Major bug fixes applied to the
next minor release.
x.y.2 releases have all Blocker, Critical bug fixes applied to the next
minor release.
x.y.3 releases have all Blocker bug
If people are concerned about regression then just don't install new
versions, or install a vendor tested stable version. Giving users choices
is a good thing for stability.
On Wed, Jul 15, 2015 at 2:17 PM, Sangjin Lee sjl...@gmail.com wrote:
I think the bar for making the maintenance releases
Every new patch potentially brings in new bugs. So, if we want to limit the
kinds of potential bugs introduced in point releases, we might want to
limit what gets in.
Would be nice to make sure a point release is more stable than a previous
point release in that line.
On Wed, Jul 15, 2015 at
I think the bar for making the maintenance releases should be set
reasonably high, and the main reason is the concern for
stability/regression. Unfortunately there have been cases where a seemingly
innocuous bug fix introduced regressions, small or large. And that defeats
the purpose of a
Why not just include all backwards compatible bug fixes?
Alternatively, why not appoint a Release Manager for the minor release line
and then allow them to arbitrate when there's disagreement about inclusion?
This has worked well in the HBase community.
On Wed, Jul 15, 2015 at 3:49 PM, Karthik
I can understand these (sort of newish) questions from hbase-dev. We already
have a well laid-out release-management process. If people want to learn more
about how it works, please head over to http://hadoop.apache.org/bylaws.html.
In terms of 2.6.1 release management, it wasn’t stuck for lack
On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey bus...@cloudera.com wrote:
Alternatively, why not appoint a Release Manager for the minor release line
and then allow them to arbitrate when there's disagreement about inclusion?
This has worked well in the HBase community.
Release managers aren't
] Additional maintenance releases for Hadoop 2.y
versions
On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey bus...@cloudera.com wrote:
Alternatively, why not appoint a Release Manager for the minor release
line
and then allow them to arbitrate when there's disagreement about
inclusion?
This has worked well
Strong +1 for having a 2.6.1 release. I understand Vinod has been trying to
get that effort going but it's been stalled a little bit. It would be good
to rekindle that effort.
Companies with big hadoop 2.x deployments (including mine) have always
tried to stabilize a 2.x release by
I believe there was general consensus to do more maintenance releases, as
witnessed in the other thread.
There have been discussions on what should go into 2.x.1, 2.x.2, etc., but
I don't think we have a clear proposal. It would be nice to put that
together, so committers know where all to commit
Thank you for the notification. Trying to back port bug fixes.
- Tsuyoshi
On Wed, Jul 15, 2015 at 3:45 AM, Sean Busbey bus...@cloudera.com wrote:
Hi Hadoopers!
Over in HBase we've been discussing the impact of our dependencies on our
downstream users. As our most fundamental dependency,
Thanks Sean for starting this thread.
I started almost the same discussion[1] before, so I'm obviously +1 for
creating 2.6.1 release. I'd like to start the work ASAP.
[1] http://s.apache.org/MMR
Regards,
Akira
On 7/15/15 03:45, Sean Busbey wrote:
Hi Hadoopers!
Over in HBase we've been
Hi Hadoopers!
Over in HBase we've been discussing the impact of our dependencies on our
downstream users. As our most fundamental dependency, Hadoop plays a big
role in the operational cost of running an HBase instance.
Currently the HBase 1.y release line supports Hadoop 2.4, 2.5, and 2.6[1].
26 matches
Mail list logo
