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

Regarding tests. I would suggest we have different rules for trunk and branches:

(1) For branches, I think we should run the full regression suite (including e2e) prior to commit. This way we can ensure branch stability and, as number of patches should be small, will not be a burden
(2) For trunk, we can go with test-commit only and fix things quickly when things break.

Olga
________________________________
From: Gianmarco De Francisci Morales <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; Olga Natkovich <[EMAIL PROTECTED]>
Sent: Monday, November 5, 2012 10:37 AM
Subject: Re: Our release process

Hi,

Sure we don't want to commit patches that destabilize the code base.
However, unfortunately, there is no way to know whether a patch will
destabilize the code or not. Even testing is only a heuristic. So how do we
draw the line?
We seem to agree that only bug fixing should go into branches. However it
seems that we have two different views on the policy: Olga is proposing to
have only P1 bugs fixed, while Alan is suggesting to be more lax on what
goes into the branches.
Regardless of the policy chosen, how do we define the priority of a bug? By
how many users are affected? By whether it can corrupt data? Is there a
formal definition we can agree on? Otherwise defining a policy becomes hard.

The test-commit task does not run full regression because the full test
suite takes too long to execute. And I agree that asking to run the full
test suite before committing any change slows down the (already slow)
review process.
However, I would be fine with running the full test suite for bug fixes
that need to go into branches, in order to guarantee absence of regressions.

Cheers,
--
Gianmarco

On Sun, Nov 4, 2012 at 5:17 PM, Olga Natkovich <[EMAIL PROTECTED]> wrote:

> I can see how this would work for research projects but for real
> production this will not work. And I actually meant much more stringent
> stability. I don't think we should commit patches to either trunk or branch
> that destabilize the tree. We used to run full regression before each
> commit - is this no longer the case? By stability I meant very few things
> go into the branch. I know that pig has pretty decent tests - better
> coverage than many other projects. However, we do not have any testing at
> scale and inevitably, users end up doing testing. So any time we deploy new
> major version, it takes us at least a month to get it stable and once it is
> stabilized we want to keep it this way.
>
> So for us at Yahoo, the only way to work directly from the branch is to go
> by our original plan. If that is not possible, we would go with the private
> git branch.
>
> Olga
>
>
> ________________________________
>  From: Alan Gates <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, November 2, 2012 8:19 PM
> Subject: Re: Our release process
>
> I am all for maintaining stability of branches, and the trunk, as everyone
> benefits from it.  But I do not think this means we should limit bug fixing
> in the branches to only critical issues.  As Pig gets more users we have
> more and more people on older branches who will want fixes for bugs without
> dealing with bigger version changes.  So I am not in favor of limiting
> checkins to branches to P1 issues.
>
> What if we maintain stability on the branches by quickly reverting any
> patches that break the build, the unit tests, or the e2e tests?  This
> allows us to move forward with bug fix versions, it allows those who depend
> on branch stability (which I suspect is everyone in the distribution
> business plus everyone rolling their own Pig), and it should promote
> developer responsibility (no one likes having their patches reverted).
>
> Alan.
>
> On Nov 2, 2012, at 3:58 PM, Olga Natkovich wrote: