Bringing 'organizations' into this discussion is very disingenuous.
Doug, credit to him, was the first person to propose this release:
http://www.mail-archive.com/[email protected]/msg01427.html
I have supported the append-release:
http://www.mail-archive.com/[email protected]/msg02584.html
So, stop coloring arguments in this manner.
Arun
On Jan 17, 2011, at 8:30 PM, Jeff Hammerbacher wrote:
Hey,
We had this exact same discussion about the 0.20-append branch a few
weeks
ago. A few organizations have tested that code at scale and feel
strongly
that it's stable. We decided not to release it because it does not
meet the
Apache guidelines for a release. The Apache process has its pros and
cons;
we've all accepted them, so the community moved on and focused its
energy on
the 0.22 release.
A few weeks later, we now have another organization claiming that
their
0.20-based branch is tested at scale and should be released. It's
claimed
that 0.20.100 will be "more stable, performant and more useful to our
users"; the same can be said of the 0.20-append branch. Neither
branch,
however, is a bugfix release and thus does not meet the Apache
guidelines
for a release. That's too bad; we should work to avoid this
situation again
in the future, but let's not try to change the rules because we did
a poor
job in the past of getting our work released via Apache.
As Nigel mentions, and as was done with 0.20-append, I would fully
support a
"a code-only drop into a branch w/ no formal Apache release". That's
fully
compliant with the Apache process.
All of these discussions will be moot once we get 0.22 out the door
and stop
arguing over which organization has the most magical 0.20-based
bits. I'm
looking forward to seeing all of the Apache Hadoop contributors
working full
time on that release process once these bits are committed to the
0.20.100
branch.
Thanks,
Jeff
On Mon, Jan 17, 2011 at 6:55 PM, Todd Papaioannou <toddp@yahoo-
inc.com>wrote:
That's only true if you plan to pull forward the changes wholesale
into
.21, .22 and beyond. And that is not what is being proposed.
If the plan is to just land an updated and more stable version of .
20 that
is completely backwards compatible, then this can be done within
that code
line without any impact to the end users. Any changes that the
community
wish to pull forward can be identified, isolated and reviewed per
the normal
process. Or they can remain in the .20.100 release for eternity,
without any
impact on the future.
Either way, the .20 release will be more stable, performant and
more useful
to our users, and the community at large can focus on releasing .
22, which
we all believe is the right goal.
ToddP
From: Doug Cutting <[email protected]<mailto:[email protected]>>
Reply-To:
"[email protected]<mailto:[email protected]>" <
[email protected]<mailto:[email protected]>>
Date: Mon, 17 Jan 2011 15:49:51 -0800
To: "[email protected]<mailto:[email protected]>" <
[email protected]<mailto:[email protected]>>
Subject: Re: [DISCUSS] Hadoop Security Release off Yahoo! patchset
Backwards compatibility has been a goal, so
with luck we will not ID regressions.
My point was that, in addition to back-compatibility with prior 0.20
releases, we must also consider the forward-compatibility of each
change
with 0.21, 0.22 and trunk.
