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
Jonathan Coveney 2012-12-13, 21:14
Olga,

A related but separate question: what do y'all do when there is a feature
that is finished, but for an upcoming release? ie a feature in trunk, but
not in 0.11 (which, let us assume, is stable).

Jon
2012/12/13 Olga Natkovich <[EMAIL PROTECTED]>

> Hi Julien,
>
> I think for us at Yahoo to be able to run our releases directly from the
> branch we would need the guarantees that I proposed in my initial email and
> something that we agreed to last year. The only changes that go in are
>
> - Failures without reasonable workarounds
> - Silent failures.
>
> My main concerns with the proposal is that I do not believe that our
> current testing infra is robust/inclusive enough to catch errors. That's
> why I am hesitant in widening the scope.
>
> I am fine with whatever the outcome the majority of people agrees with. I
> am just saying that Yahoo will likely need a private branch if our rules
> are too relaxed.
>
> Olga
>
>
>
> ----- Original Message -----
> From: Julien Le Dem <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Olga Natkovich <
> [EMAIL PROTECTED]>
> Cc:
> Sent: Wednesday, December 12, 2012 4:54 PM
> Subject: 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 <