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

Switch to Threaded View
Pig >> mail # dev >> Re: Our release process


Copy link to this message
-
Re: Our release process
Agreed. The priority of a change is subjective as well.
My definition for inclusion on the release branch:
- Only bug fixes.
- Only if they have fairly understood repercussions (up to the committers
who +/-1 as usual).
- If we thought it would not break things but still does (CI or externally
reported failure) we revert it.
What do you want to add/change? Please reformulate those rules the way you
like and let's see how we can converge.
(Also, let's keep it short for clarity)

Julien

On Wed, Dec 12, 2012 at 11:08 AM, Olga Natkovich <[EMAIL PROTECTED]>wrote:

> Hi Julien,
>
> I understand what you are trying to do and I can see that being able to
> make more fixes post release has value for some use cases. My concern is
> that "things that do not destabilize the branch" is fairly subjective and
> also not always easy to ascertain beyond trivial changes. The only way I
> know to keep a code stable is to limit the updates. Also we need to clearly
> state what the constrains are for a post release commits so that every user
> can decide whether it works for them.
>
> Olga
>
>
> ________________________________
> From: Julien Le Dem <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 12, 2012 10:26 AM
> Subject: Re: Our release process
>
> I think we all agree here, let's not jump to conclusions.
> Everything in this branch I am talking about is in Apache Pig. Everything
> we do in Pig is contributed.
> We have a branch for 0.11 where we keep merging the official 0.11 branch
> plus a few patches (and it will stay small) that are only in Apache TRUNK.
> The goal here is to help keeping the release branch stable by not adding
> patches that are only useful to us.
> Having this branch allows us to fix anything quickly and redeploy to
> production. It is also what allows us to use the pig 0.11 branch in
> production before it is even released.
> This definitely benefits the community and helps making 0.11 stable.
> This is a very reasonable way to keep using a recent version of Pig in
> production.
>
> Olga: My goal is to decrease the scope of what is going in the release
> branch and to make sure we add only bug fixes that are not making it
> unstable. I also think having a short definition of this helps which is why
> I have been chiming in.
> Let us know how you want to decrease the scope. I'm just trying to simplify
> here.
>
> Julien
>
>
>
> On Tue, Dec 11, 2012 at 8:54 AM, Prashant Kommireddi <[EMAIL PROTECTED]
> >wrote:
>
> > Share the same concern as Russell here. Not great for the project for
> > everyone to go "private branch" approach.
> >
> > On Tue, Dec 11, 2012 at 8:33 AM, Russell Jurney <
> [EMAIL PROTECTED]
> > >wrote:
> >
> > > Wait. Ack. Do we want everyone to do this? This sounds like
> > fragmentation.
> > > :(
> > >
> > > Russell Jurney twitter.com/rjurney
> > >
> > >
> > > On Dec 10, 2012, at 3:24 PM, Olga Natkovich <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > If everybody is using a private branch then
> > > >
> > > > (1) We are not serving a significant part of our community
> > > > (2) There is no motivation to contribute those patches to branches
> > (only
> > > to trunk).
> > > >
> > > > Yahoo has been trying hard to work of the Apache branches but if we
> > > increase the scope of what is going into branches, we will go with
> > private
> > > branch approach as well.
> > > >
> > > > Olga
> > > >
> > > >
> > > > ________________________________
> > > > From: Julien Le Dem <[EMAIL PROTECTED]>
> > > > To: Olga Natkovich <[EMAIL PROTECTED]>
> > > > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Santhosh M S <
> > > [EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <
> [EMAIL PROTECTED]
> > >
> > > > Sent: Friday, December 7, 2012 3:54 PM
> > > > Subject: Re: Our release process
> > > >
> > > > Here's my criteria for inclusion in a release branch:
> > > > - no new feature. Only bug fixes.
> > > > - The criteria is more about stability than priority. The