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
Hi Olga,

Daniel has cut the 0.10.1 branch and the release candidate is up for a vote. I think its reasonable to expect such releases where there are a lot of bug fixes. In 0.10.1 there are 48 fixes in all.

The list of bug fixes does not fit the criteria of being having no workaround or failing silently.

Does that work for? 
 From: Olga Natkovich <[EMAIL PROTECTED]>
Sent: Monday, December 17, 2012 4:16 PM
Subject: Re: Our release process
Hi Jonathan,

I thought I answered your email last week but I just noticed that the answer did not come through.

We tell users that at is coming in the next release. Now that Pig is quite mature and stable, we don't see much of this. Having more frequent releases definitely helps in this respect.


From: Jonathan Coveney <[EMAIL PROTECTED]>
Sent: Thursday, December 13, 2012 1:14 PM
Subject: Re: Our release process


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).

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 <
> 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]>
> > 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
> > The goal here is to help keeping the release branch stable by not adding