Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Security roadmap [Was: Release plans]


Copy link to this message
-
Security roadmap [Was: Release plans]
https://issues.apache.org/jira/browse/HADOOP-4487. Please start a new thread
next time.

On Mon, Feb 22, 2010 at 12:40 AM, Evert Lammerts <[EMAIL PROTECTED]>wrote:

> I'm sorry for breaking into your discussion as an outsider, but I'm very
> curious about the security features you are planning to roll out in March.
> Where can I find information about this?
>
> Best regards,
> Evert Lammerts
>
> > -----Original Message-----
> > From: Jay Booth [mailto:[EMAIL PROTECTED]]
> > Sent: maandag 22 februari 2010 5:55
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Release plans
> >
> > Well, since someone has to get the ball rolling as far as release
> > masters, I'll nominate Stack and/or someone hbase related for 0.21
> > with the primary goal of being "soon"?  They get a big win from append
> > and others will gain from the expanded mapreduce lib, better
> > schedulers, etc. There are a lot of new features and some major
> > changes (project split) already in the 0.21 branch, so IMO it's worth
> > considering a release with minimal backports, rather than make binding
> > decisions about 0.22 before 0.21 is even in the wild.
> >
> > -Jay
> >
> > PS sorry Stack
> >
> > On Feb 20, 2010, at 5:04 PM, Stack <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Feb 19, 2010 at 4:23 PM, Eli Collins <[EMAIL PROTECTED]>
> > wrote:
> > >> Can we make a decision on basing 21 on the current branch and if
> > it's
> > >> decided that 22 can't remove stuff that was in 20 we'll go back and
> > >> do
> > >> the necessary additions on 21 and trunk? Suspect that decision will
> > >> take a lot more back and forth, but needs to conclude before 21 is
> > >> released.
> > >>
> > >
> > > Lets.
> > >
> > > Regards 0.21/current-branch release, as has been suggested above,
> > > first we need to figure the release master.  No release master, no
> > > release.  If we have a release master, then I suggest we vote on
> > > current branch being released as 0.21 as soon as the blockers are
> > > cleared.
> > >
> > > I don't think we need muddy the above vote with whether or not 0.21
> > > maintains API combatibility with 0.20.  IMO, it must (because Y! want
> > > to have the 0.20 API in place when January 2011 rolls around).  This
> > > makes 0.21 a "minor" release -- something we've not done before (For
> > > the record, I also had a misunderstanding that what we were doing up
> > > to this was major and patch only).  So, part of the release process
> > > would involve ensuring no removed deprecations, etc.
> > >
> > > As DC has been saying, this requirement that releases between now and
> > > January 2011 not change APIs makes 0.20 retroactively into a "major"
> > > release.  0.20 is the release where major shifted left in our
> > > versioning scheme and minor releases came into play.  0.21 and 0.22
> > > will be minor releases. Can we just acknowledge this fact, that there
> > > was a step at version 0.20, update the wiki around versioning -- its
> > > currently wrong anyways as Elis' points out -- and just move on?
> > > Going back and calling 0.20 a 1.0 seems more apt to create confusion
> > > and besides, I'm with Allen that hadoop 1.0 needs wire compatibility
> > > before the 1.0 can roll around.
> > >
> > > Thanks,
> > > St.Ack
> > > P.S. +1 on branching as soon as avro and security are in, etc.
>