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: > Hi guys, > > Mid next year, we agreed on a release process documented in this thread: > http://www.mail-archive.com/[email protected]/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
