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

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

Copy link to this message
Re: Our release process
It takes too long to run. If the e2e tests are run every night or a reasonable timeframe then it will reduce the barrier for submitting patches. The context for this: the reluctance of folks to move to a higher version when the higher version is not backward compatible.

 From: Olga Natkovich <[EMAIL PROTECTED]>
Sent: Sunday, November 25, 2012 5:56 PM
Subject: Re: Our release process
Hi Santhosh,

Can you clarify why running e2e tests on every checking is a problem?

From: Santhosh M S <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2012 3:48 PM
Subject: Re: Our release process

The push for an upgrade will work only if the higher release is backward compatible with the lower release. If not, folks will tend to use private branches. Having a stable branch on a large deployment is a good indicator of stability. However, please note that there have been instances where some releases were never adopted. I will be extremely careful in applying the rule of running e2e tests for every commit to a released branch.

If we release every quarter (hopefully) and preserve backward compatibility then I am +1 to the proposal. If the backward compatibility is not preserved then I am -1 for having to run e2e for every commit to a released branch.

From: Jonathan Coveney <[EMAIL PROTECTED]>
Sent: Tuesday, November 6, 2012 6:34 PM
Subject: Re: Our release process

I think it might be good to clarify (for me) a couple of cases:

1. we have branched a new release
2. an existing release

The way I understand things, in the case of 1, we have a backlog of patches
(not all of which are P1 bugs), and that's ok. If a new bad bug comes in
(the subject of debate here), then it goes in anyway (and in some cases,
would go into 0.9 etc).

Olga is saying that for existing release (0.9, 0.10), we should only commit
P1 bug fixes there. This makes sense to me, as we're fixing the "official
release" in place.

IMHO, this would encourage people to use newer release (as this is where
the latest and greatest stuff is, including non-critical bug fixes). Olga's
criteria is a pretty clear barrier for inclusion into these releases. With
old releases, I think the key is really that they keep doing what they have
always done. Most bugs are well understood by now, and the ones that aren't
will no doubt be P1.

I'm not decided (thus no formal +1 or whatnot), but Olga's point seems
pretty reasonable to me, especially given that trunk has pretty liberal
development. Once it gets tidied up, I can understand not wanting to jostle
2012/11/5 Alan Gates <[EMAIL PROTECTED]>

> Jonathan, for clarity, are you saying you agree that we should only put
> bug fixes in branches or we should only put high priority bug fixes in
> branches?  I think we all agree on the former, but there appear to be
> different views on the latter.
> Alan.
> On Nov 5, 2012, at 4:53 PM, Jonathan Coveney wrote:
> > This seems to make sense to me. People can always back-port features, and
> > this encourages them to use the newer ones. It also means we will be more
> > rigorous about stability, which is good as it is a big plus for Pig. I
> > think for older branches, stability trumps features in a big way.
> >
> >
> > 2012/11/5 Gianmarco De Francisci Morales <[EMAIL PROTECTED]>
> >
> >> Hi,
> >>
> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga Natkovich <[EMAIL PROTECTED]>
> >> wrote:
> >>> Hi Gianmarco,
> >>>
> >>> Thanks for your comments. Here is a little more information.
> >>>
> >>> At Yahoo, we consider the following issues to be P1:
> >>>
> >>> (1) Bugs that cause wrong results being produced silently
> >>> (2) Bugs that cause failures with no easy workaround
> >>>
> >>