hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Baldeschwieler <eri...@yahoo-inc.com>
Subject Re: Release compatibility was Re: [VOTE] Release candidate
Date Sun, 08 May 2011 18:10:22 GMT
I'd agree with this too. [same disclaimer as milind, not on PMC]

In general one would not expect to see an incompatible change added in a dot release (0.24.1
0.24.2).  I'd expect anything like that to require community discussion and support.

As milind summarized, we seem to have support for the addition of security to 20.  The existing
mechanism of the required release vote will confirm or deny that.

I think it is important that compatible enhancements to hadoop are allowed into dot releases.
 This is something that we've discussed but never finalized in the community.  It is the desire
to put improvements into users hands more quickly that the next major release that drives
orgs to produce private releases of hadoop.  In general, I think it is fair that such changes
go into trunk first.  Exceptions to that also need discussion and support IMO.

I think the key to making progress is discussion and the idea that majority support, not consensus
is what is needed to make exceptions to our process.  Process is useful, it reduces friction.
 Process without exception is stifling.  

On May 7, 2011, at 10:52 PM, Milind Bhandarkar wrote:

> [Mentioning again: I am not on the PMC, and this email contains
> non-binding opinions based on my reading the general@hadoop.apache.org
> emails.]
> It is my understanding that, from the beginning, the 0.20+security was
> always treated as an exception to the normal (I.e. Pre-0.20) release
> process. (This has been confirmed by the mailing list threads, in which
> many of those who are objecting to this release now - stating that it has
> violated norms - have consented, actually argued for, breaking the norms.)
> For whatever I have read on this mailing list before the vote for this
> release, it looked like most of the community agreed that what Yahoo! Had
> produced on their own branch, outside of Apache trunk, was important
> contribution, and a release based on that would be a good idea, and that a
> one-time release should proceed. (After all, whichever organization the
> contributors belong to, many seem to indicate that they feel ashamed not
> having an Apache release in more than a year.)
> From many emails on this thread, it has been clear to me, that it is a one
> time concession given for parting ways from the normal process, and I hope
> everyone understands that this is supposed to make Apache Hadoop releases
> relevant once again.
> So, to cut it short, the 0.20.203 backward incompatibilities etc have no
> bearing on the "normal" process, in which no backward incompatibilities
> should be allowed in minor releases. To answer your specific question, I
> have no reason to believe that 0.22.1 could be backward incompatible with
> 0.22.0. 
> - milind
> -- 
> Milind Bhandarkar
> mbhandarkar@linkedin.com
> +1-650-776-3167
> On 5/7/11 4:50 PM, "Eric Sammer" <esammer@cloudera.com> wrote:
>> Milind:
>> Thanks for the pointer. I remember this thread. I guess my question
>> was unrelated to the specific release and more about the general mode
>> of development under normal release circumstances (ie. do we permit
>> backward incompatible changes between 0.22.0 and 0.22.1 or is this
>> something we've allowed just for the 203 release?).
>> I think it's important to be clear about what the MO is so end users
>> can plan upgrades appropriately.
>> Thanks!
>> Sammer
>> On May 6, 2011, at 11:52 PM, Milind Bhandarkar <mbhandarkar@linkedin.com>
>> wrote:
>>> [I am not on PMC, but seeing that PMC may be busy with other issues, I
>>> will try to answer your questions.]
>>> Eric,
>>> I think the thread
>>> "http://mail-archives.apache.org/mod_mbox/hadoop-general/201101.mbox/%3C1
>>> 8C
>>> 5C999-4680-4684-BC55-A430C40FD746@yahoo-inc.com%3E" will answer your
>>> questions. Here is the timeline as I see it:
>>> 1. Arun proposes to create a release from the security patchset. Says
>>> Doug
>>> has proposed this earlier
>>> (http://mail-archives.apache.org/mod_mbox/hadoop-general/201004.mbox/%3C4
>>> BD
>>> 1DFEA.5020908@apache.org%3E April 23, 2010) ("This has been proposed
>>> earlier by Doug and did not get far due to concerns about the effect
>>> this
>>> would have on development on trunk.") (August 24, 2010)
>>> 2. Lots of +1s, between August 24 to August 30 2010. One particular
>>> comment is from Tom White: "I think it would be good to have a shared
>>> 0.20
>>> Apache security branch.
>>> Since security isn't in 0.21, and the 0.22 release is a some way off
>>> as you mention, this would be useful for folks who want the security
>>> features sooner (and want to use an Apache release)."
>>> 3. Arun volunteers to create a release (August 30, 2010)
>>> 4. Doug reminds Arun. (October 15, 2010)
>>> 5. Arun apologizes for not creating a branch because he was busy,
>>> because
>>> he had a baby. (January 11, 2011)
>>> 6. Lots of discussion about what to call it (the release, not the baby,
>>> although I had a good laugh at Patrick Angeles's email: "You're gonna
>>> call
>>> your kid 20.100?" ;-).
>>> 7. Arun proposes to call it 0.20.100: "I'm open to suggestions - how
>>> about
>>> something like 20.100 to show that it's a big jump? Anything else?" Jan
>>> 12, 2011
>>> 8. Among others, Eli says: "+1 on 0.20.x   (where x is a J > 3)" on Jan
>>> 12, 2011.
>>> So, as you can see, even if this release is called 0.20.x, the community
>>> agreed that these are valuable patches to have, and despite backward
>>> incompatibility, still have them in minor release.
>>> - milind
>>> --
>>> Milind Bhandarkar
>>> mbhandarkar@linkedin.com
>>> +1-650-776-3167
>>> On 5/6/11 11:14 PM, "Eric Sammer" <esammer@cloudera.com> wrote:
>>>> On May 6, 2011, at 4:53 AM, Steve Loughran <stevel@apache.org> wrote:
>>>> I understand Eli's concerns that putting stuff in there that hasn't
>>>> gone
>>>> into trunk yet is danger. However, as the team makes no guarantees of
>>>> 100%
>>>> compatibility between releases, I don't think it's critical. It's just
>>>> something that needs to be addressed -which can be done after this
>>>> release
>>>> has shipped.
>>>> I was under the impression that the community has been extremely strict
>>>> about compatibility between minor version bumps in the past. I though
>>>> there
>>>> were specific guarantees and that was one of the reasons certain
>>>> behaviors
>>>> have persisted so long.
>>>> Does this mean API changes can be made in minor releases and it can be
>>>> made
>>>> backward compatible in future releases? That seems very, very counter
>>>> to
>>>> various conversations that have happened in the past. I'm of the mind
>>>> that
>>>> we should continue to promise what we've always promised and if that's
>>>> changing, let's make with the refactoring party!
>>>> Can some PMC'ers clarify this one for me?
>>>> TIA.
>>>> Sammer
>>>> -Steve

View raw message