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-candidate<https://issues.apache.org/jira/issues/?jql=labels%20=%202.6.1-candidate>,
 in order to make progress while the issue is still hot.

The discussion is continuing on the 2.6.1 release planning thread.

Thanks
+Vinod

On Jul 15, 2015, at 6:09 PM, Andrew Purtell 
<apurt...@apache.org<mailto:apurt...@apache.org>> wrote:

Inline

On Wed, Jul 15, 2015 at 5:22 PM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com<mailto: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
http://hadoop.apache.org/bylaws.html.

In terms of 2.6.1 release management, it wasn’t stuck for lack of
volunteers for RM. I originally was driving it [1], and then Akira recently
volunteered too in a separate thread [2] (which I totally missed
participating in before), so we have enough help.


​Right, but in that thread it looks like you were stymied sorting through
the potential set of updates to apply to the patch release. That was the
motivation behind my sharing a bit about HBase branch RMs. Totally fine if
that's not something Hadoop wants to explore. I only offered it as a data
point where another project avoids that problem with a different kind of RM
focus. And, so, that's that FWIW




It is clearly acknowledged there is a demand for 2.6.1, we now have to
figure out the mechanics, agreeing on a reasonable & common list of fixes
to start with.


​Thank you very much for this consideration!​



Tx for the feedback so far @hbase-dev! I agree with Karthik earlier -
let’s continue the discussion in hadoop-dev in the release thread [1] for
2.6.1.

Thanks
+Vinod

[1] Planning Hadoop 2.6.1 release
http://markmail.org/message/sbykjn5xgnksh6wg
[2] [DISCUSS] More Maintenance Releases http://s.apache.org/MMR

On Jul 15, 2015, at 4:07 PM, Stack <st...@duboce.net<mailto:
st...@duboce.net>> wrote:

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 <cdoug...@apache.org
<mailto:cdoug...@apache.org>> wrote:

On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey <bus...@cloudera.com<mailto:
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 appointed in Hadoop. Any committer can RM a
release branch and encourage others to help with it. An RM can set the
bar arbitrarily, but an RC only becomes a release when a majority of
PMC votes approve it in a VOTE. -C

On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey <bus...@cloudera.com<mailto:
bus...@cloudera.com>> wrote:
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 Kambatla <ka...@cloudera.com
<mailto:ka...@cloudera.com>>
wrote:

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 fixes applied to next minor release.

Here I am assuming there are no security-fix-only or other urgent
releases.

We could apply this approach for 2.7.x onwards, and do an adhoc 2.6
release.

On Wed, Jul 15, 2015 at 12:59 PM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com<mailto:vino...@hortonworks.com>> wrote:

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 bug-fixes that went into 2.7.x and into branch-2.8, figuring
out
a set of patches that is acceptable for everyone is a huge challenge
which
kind of stalled my attempts.

Thanks
+Vinod


On Jul 15, 2015, at 8:57 AM, Sangjin Lee <sjl...@gmail.com<mailto:
sjl...@gmail.com>> wrote:

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 testing/collecting/researching
critical
issues on the release. Each would come up with its own set of fixes
to
backport. We would also communicate it via offline channels. During
the
hadoop summit, we thought it would be great if we all came together
and
create a public stability/bugfix release on top of 2.x (2.6.1 for
2.6
for
example) with all the critical issues fixed.

Thanks,
Sangjin


On Tue, Jul 14, 2015 at 10:42 PM, Tsuyoshi Ozawa <oz...@apache.org<mailto:
oz...@apache.org>>
wrote:

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<mailto:
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, 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].
We don't drop Hadoop minor release lines in minor releases so we
are
unlikely remove anything from this set until HBase 2.0, probably
at
the
end
of 2015 / start of 2016 (and currently we plan to continue
supporting
at
least 2.4 for HBase 2.0 [2]). Lately we've been discussing
updating
our
shipped binaries to Hadoop 2.6, following some stability testing
by
part
of
our community[3]. Unfortunately, 2.6.0 in particular has a couple
of
bugs
that could destroy HBase clusters should users decide to turn on
HDFS
encryption[4]. Our installation instructions tell folks to replace
these
jars with the version of Hadoop they are actually running, but not
all
users follow those instructions so we want to minimize the pain
for
them.

Regular maintenance releases are key to keeping operational
burdens
low
for
our downstream users; we don't want them to be forced to choose
between
living with broken systems and stomaching the risk of upgrades
across
minor/major version numbers. Looking back over the three
aforementioned
Hadoop versions, 2.6 hasn't had a patch release since 2.6.0 came
out
in
Nov
2014, when 2.5 had its last patch release as well. Hadoop 2.4
looks
to
be a
year without a release[5]. On our discussion of shipping Hadoop
2.6
binaries, one of your PMC members mentioned that with continued
work
on
the
2.7 line y'all weren't planning any additional releases of the
earlier
minor versions[6].

The HBase community requests that Hadoop pick up making
bug-fix-only
patch
releases again on a regular schedule[7]. Preferably on the 2.6
line
and
preferably monthly. We realize that given the time gap since
2.6.0 it
will
likely take a big to get 2.6.1 together, but after that it should
take
much
less effort to continue.

[1]: http://hbase.apache.org/book.html#hadoop
[2]: http://s.apache.org/ReP
[3]: HBASE-13339
[4]: HADOOP-11674 and HADOOP-11710
[5]: http://hadoop.apache.org/releases.html
[6]: http://s.apache.org/MTY
[7]: http://s.apache.org/ViP

--
Sean





--
Karthik Kambatla
Software Engineer, Cloudera Inc.
--------------------------------------------
http://five.sentenc.es




--
Sean





--
Best regards,

  - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Reply via email to