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 <onatkov...@yahoo.com> 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 <ga...@hortonworks.com> > To: dev@pig.apache.org > 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: > > > Hi guys, > > > > Mid next year, we agreed on a release process documented in this thread: > http://www.mail-archive.com/dev@pig.apache.org/msg04172.html. > > > > Since then, we have not really followed either of its two rules: > > > > (1) Frequent (every 3 month releases) > > (2) Branch stability (only P1 issues on the branch). > > > > So I wanted to revisit our release procedure to make sure we have one > that we can actually follow. > > > > For us at Yahoo, branch stability is very important since we release all > the patches directly from the branch. If we can't rely on the fact that > only critical fixes go in, we will need to resort to git branches that will > make the whole process very comberson because we now need to hand pick > patches from the apache branch and port them onto our private branch. I > would imaging that others using Pig in production would have similar issues. > > > > Olga > > > > > > Olga >
