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 <jul...@twitter.com> To: "dev@pig.apache.org" <dev@pig.apache.org>; Olga Natkovich <onatkov...@yahoo.com> 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 <onatkov...@yahoo.com>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 <jul...@twitter.com> > To: "dev@pig.apache.org" <dev@pig.apache.org> > 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 TRUNK. > The goal here is to help keeping the release branch stable by not adding > patches that are only useful to us. > Having this branch allows us to fix anything quickly and redeploy to > production. It is also what allows us to use the pig 0.11 branch in > production before it is even released. > This definitely benefits the community and helps making 0.11 stable. > This is a very reasonable way to keep using a recent version of Pig in > production. > > Olga: My goal is to decrease the scope of what is going in the release > branch and to make sure we add only bug fixes that are not making it > unstable. I also think having a short definition of this helps which is why > I have been chiming in. > Let us know how you want to decrease the scope. I'm just trying to simplify > here. > > Julien > > > > On Tue, Dec 11, 2012 at 8:54 AM, Prashant Kommireddi <prash1...@gmail.com > >wrote: > > > Share the same concern as Russell here. Not great for the project for > > everyone to go "private branch" approach. > > > > On Tue, Dec 11, 2012 at 8:33 AM, Russell Jurney < > russell.jur...@gmail.com > > >wrote: > > > > > Wait. Ack. Do we want everyone to do this? This sounds like > > fragmentation. > > > :( > > > > > > Russell Jurney twitter.com/rjurney > > > > > > > > > On Dec 10, 2012, at 3:24 PM, Olga Natkovich <onatkov...@yahoo.com> > > wrote: > > > > > > > If everybody is using a private branch then > > > > > > > > (1) We are not serving a significant part of our community > > > > (2) There is no motivation to contribute those patches to branches > > (only > > > to trunk). > > > > > > > > Yahoo has been trying hard to work of the Apache branches but if we > > > increase the scope of what is going into branches, we will go with > > private > > > branch approach as well. > > > > > > > > Olga > > > > > > > > > > > > ________________________________ > > > > From: Julien Le Dem <jul...@twitter.com> > > > > To: Olga Natkovich <onatkov...@yahoo.com> > > > > Cc: "dev@pig.apache.org" <dev@pig.apache.org>; Santhosh M S < > > > santhosh_mut...@yahoo.com>; "billgra...@gmail.com" < > billgra...@gmail.com > > > > > > > Sent: Friday, December 7, 2012 3:54 PM > > > > Subject: Re: Our release process > > > > > > > > Here's my criteria for inclusion in a release branch: > > > > - no new feature. Only bug fixes. > > > > - The criteria is more about stability than priority. The > person/group > > > > asking for it has a good reason for wanting it in the branch. If > > > commiters > > > > think the patch is reasonable and won't make the branch unstable then > > we > > > > should check it in. If it breaks something anyway, we revert it. > > > > > > > > For what it's worth we (at Twitter) maintain an internal branch where > > we > > > > add patches we need and I would suggest anybody that wants to be able > > to > > > > make emergency fixes to their own deployment to do the same. We do > keep > > > > that branch as close to apache as we can but it has a few patches > that > > > are > > > > in trunk only and do not satisfy the no new feature criteria. > > > > > > > > What does the PMC think ? > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > On Tue, Dec 4, 2012 at 12:46 PM, Olga Natkovich < > onatkov...@yahoo.com > > > >wrote: > > > > > > > >> I am ok with tests running nightly and reverting patches that cause > > > >> failures. We used to have that. Does anybody know what happened? Is > > > anybody > > > >> volunteering to make it work again? > > > >> > > > >> I would like to see specific criteria for what goes into the branch > > been > > > >> published (rather than case-by-case). This way each team can decided > > if > > > the > > > >> criteria stringent enough of if they need to run a private branch. > > > >> > > > >> Olga > > > >> > > > >> ------------------------------ > > > >> *From:* Santhosh M S <santhosh_mut...@yahoo.com> > > > >> *To:* Julien Le Dem <jul...@twitter.com>; "dev@pig.apache.org" < > > > >> dev@pig.apache.org> > > > >> *Cc:* "billgra...@gmail.com" <billgra...@gmail.com> > > > >> *Sent:* Friday, November 30, 2012 11:46 PM > > > >> > > > >> *Subject:* Re: Our release process > > > >> > > > >> HI Julien, > > > >> > > > >> You are making most of the points that I did on this thread (CI for > > e2e, > > > >> not burdening clean e2e prior to every commit for a release branch). > > The > > > >> only point on which there is no clear agreement is the definition > of a > > > bug > > > >> that can be included in a previously released branch. I am fine > with a > > > case > > > >> by case inclusion. > > > >> > > > >> Hi Olga, > > > >> > > > >> Are you fine with Julien's proposal as it stands - bugs that are > > > included > > > >> will be determined at the time of inclusion instead of doing it now. > > > >> > > > >> Santhosh > > > >> > > > >> > > > >> ________________________________ > > > >> From: Julien Le Dem <jul...@twitter.com> > > > >> To: dev@pig.apache.org; Santhosh M S <santhosh_mut...@yahoo.com> > > > >> Cc: "billgra...@gmail.com" <billgra...@gmail.com> > > > >> Sent: Friday, November 30, 2012 5:37 PM > > > >> Subject: Re: Our release process > > > >> > > > >> Proposed criteria: > > > >> - it makes the tests fail. targets test-commit + test + e2e tests > > > >> - a critical bug is reported in a short time frame (definition of > > > >> critical not needed as it is rare and can be decided on a case by > case > > > >> basis) > > > >> > > > >> That raises another question: what are the existing CI servers > running > > > >> the tests? > > > >> - the Apache CI runs test-commit and test (is it more stable now?) > > > >> and not e2e. It would be great if it did. > > > >> - we have a Jenkins build at Twitter where we run test-commit and > > > >> test, we could not run e2e easily in our environment. > > > >> - I understand there's a Yahoo/Hortonworks build (test-commit + > test + > > > e2e > > > >> ???) > > > >> > > > >> Whenever those builds fail we should open or reopen JIRAS and fix > it. > > > >> > > > >> The time it takes to run the full > > > >> test suite makes it impractical to > > > >> run on a desktop/laptop. > > > >> > > > >> For the release Pig-0.11.0 we need to get this list of JIRAs down > to 0 > > > >> and publish the jar. > > > >> > > > >> > > > > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+PIG+AND+fixVersion+%3D+%220.11%22+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC%2C+due+ASC%2C+priority+DESC > > > >> > > > >> Julien > > > >> > > > >> On Thu, Nov 29, 2012 at 11:16 PM, Santhosh M S > > > >> <santhosh_mut...@yahoo.com> wrote: > > > >>> Looks like everyone is interested in having frequent releases - I > > don't > > > >> see anyone disagreeing with that. > > > >>> > > > >>> Regarding "If a patch > > > >> makes the release branch unstable, we revert it" - what are the > > > criteria? > > > >> If we can't decide on the criteria on this thread (already pretty > > long) > > > >> then lets get the release trains going. We can revisit the criteria > > for > > > >> inclusion of bug fixes when that happens. > > > >>> > > > >>> Santhosh > > > >>> > > > >>> > > > >>> ________________________________ > > > >>> From: Julien Le Dem <jul...@twitter.com> > > > >>> To: dev@pig.apache.org; Santhosh M S <santhosh_mut...@yahoo.com> > > > >>> Cc: "billgra...@gmail.com" <billgra...@gmail.com> > > > >>> Sent: > > > >> Thursday, November 29, 2012 9:45 AM > > > >>> Subject: Re: Our release process > > > >>> > > > >>> The release branch receives only bug fixes. Patch level releases > (3rd > > > >>> version number) are issued out of the release branch and introduce > > > >>> only bug fixes and no new features. > > > >>> Deciding whether a patch is applied to the release branch is based > on > > > >>> preserving stability (as Bill said). If a patch makes the release > > > >>> branch unstable, we revert it. > > > >>> New features are added to trunk where new major and minor releases > > will > > > >> happen. > > > >>> If we need a new feature out then we make a new minor release. > > > >>> Doing frequent releases is the industry standard and will resolve > > > >>> conflicts around what should go in a release branch. > > > >>> > > > >>> Making a new release is currently painful *because* we wait so long > > in > > > >>> between two releases. Let's fix that. > > > >>> > > > >>> Julien > > > >>> > > > >>> On Wed, Nov 28, 2012 at > > > >> 10:09 PM, Santhosh M S > > > >>> <santhosh_mut...@yahoo.com> wrote: > > > >>>> Since releasing a major version once a month is agressive and we > > have > > > >> not released on a quarterly basis, we should allow commits to a > > released > > > >> branch to facilitate dot releases. > > > >>>> > > > >>>> If we are allowing commits to a released branch, the criteria for > > > >> inclusion can be created anew or we use the industry standards for > > > severity > > > >> (or priority). It could be painful for a few folks but I don't see > > > better > > > >> alternatives. > > > >>>> > > > >>>> Regarding reverting commits based on e2e tests breaking: > > > >>>> 1. Who is running the tests? > > > >>>> 2. How often are they run? > > > >>>> If we have nightly e2e runs then its easier to catch these errors > > > >> early. If not the barrier for inclusion is pretty high and time > > > >> consuming making it harder to develop. > > > >>>> > > > >>>> Santhosh > > > >>>> > > > >>>> > > > >>>> ________________________________ > > > >>>> From: Bill Graham <billgra...@gmail.com> > > > >>>> To: dev@pig.apache.org > > > >>>> Sent: Wednesday, November 28, 2012 11:39 AM > > > >>>> Subject: Re: Our release process > > > >>>> > > > >>>> I agree releasing often is ideal, but releasing major versions > once > > a > > > >> month > > > >>>> would be a bit agressive. > > > >>>> > > > >>>> +1 to Olga's initial definition of how Yahoo! determines what goes > > > into > > > >> a > > > >>>> released branch. Basically is something broken without a > workaround > > or > > > >> is > > > >>>> there potential silent data loss. Trying to get a more granular > > > >> definition > > > >>>> than that (i.e. P1, P2, severity, etc) will be > > > >> painful. The reality in that > > > >>>> case is that for whomever is blocked by the bug will consider it a > > P1. > > > >>>> > > > >>>> Fixes need to be relatively low-risk though to keep stability, but > > > this > > > >> is > > > >>>> also subjective. For this I'm in favor of relying on developer and > > > >> reviewer > > > >>>> judgement to make that call and I'm +1 to Alan's proposal of > rolling > > > >> back > > > >>>> patches that break the e2e tests or anything else. > > > >>>> > > > >>>> I think our policy should avoid time-based consideration on how > many > > > >>>> quarters away are we from the next major release since that's also > > > >>>> impossible to quantify. Plus, if the answer to the question is > that > > > >> we're > > > >>>> more than 1-2 quarters from the next release is "yes" then we > should > > > be > > > >>>> fixing that release problem. > > > >>>> > > > >>>> > > > >>>> On Wed, Nov 28, 2012 at 10:22 AM, Julien Le Dem < > jul...@twitter.com > > > > > > >> wrote: > > > >>>> > > > >>>>> I would really like to see us doing frequent releases (at least > > once > > > >>>>> per quarter if not once a month). > > > >>>>> I think the whole notion of priority or being a "blocker" is > > > >> subjective. > > > >>>>> Releasing infrequently pressures us to push more changes than we > > > would > > > >>>>> want to the release branch. > > > >>>>> We should focus on keeping TRUNK stable as well so that it is > > easier > > > >>>>> to release and users can do more frequent and smaller upgrades. > > > >>>>> > > > >>>>> There should be a small enough number of patches going in the > > release > > > >>>>> branch so that we can get agreement on whether we check them in > or > > > >>>>> not. > > > >>>>> I like Alan's proposal of reverting quickly when there's a > problem. > > > >>>>> Again, this becomes less of a problem if we release more > > > >> often. > > > >>>>> > > > >>>>> Which leads me to my next question: what are the next steps for > > > >>>>> releasing pig 0.11 ? > > > >>>>> > > > >>>>> Julien > > > >>>>> > > > >>>>> On Tue, Nov 27, 2012 at 10:22 PM, Santhosh M S > > > >>>>> <santhosh_mut...@yahoo.com> wrote: > > > >>>>>> Hi Olga, > > > >>>>>> > > > >>>>>> For a moment, I will move away from P1 and P2 which are related > to > > > >>>>> priorities and use the Severity definitions. > > > >>>>>> > > > >>>>>> The standard bugzilla definitions for severity are: > > > >>>>>> > > > >>>>>> Blocker - Blocks development and/or testing work. > > > >>>>>> Critical - Crashes, loss of data, severe memory leak. > > > >>>>>> Major - Major loss of function. > > > >>>>>> > > > >>>>>> I am > > > >> skipping the other levels (normal, minor and trivial) for this > > > >>>>> discussion. > > > >>>>>> > > > >>>>>> Coming back to priorities, the proposed definitions map P1 to > > > Blocker > > > >>>>> and Critical. I am proposing mapping P2 to Major even when there > > are > > > >> known > > > >>>>> workarounds. We are doing this since JIRA does not have severity > by > > > >> default > > > >>>>> (see: > > > >> > https://confluence.atlassian.com/pages/viewpage.action?pageId=192840 > > > >>>>> ) > > > >>>>>> > > > >>>>>> I am proposing that P2s be included in the released branch only > > when > > > >>>>> trunk or unreleased versions are known to be backward > incompatible > > or > > > >> if > > > >>>>> the release is more than a quarter (or two) away. > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Santhosh > > > >>> > > > >>>>>> ________________________________ > > > >>>>>> From: Olga Natkovich <onatkov...@yahoo.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org>; Santhosh M S < > > > >>>>> santhosh_mut...@yahoo.com> > > > >>>>>> Sent: Tuesday, November 27, 2012 10:41 AM > > > >>>>>> Subject: Re: Our release process > > > >>>>>> > > > >>>>>> Hi Santhosh, > > > >>>>>> > > > >>>>>> What is your definition of P2s? > > > >>>>>> > > > >>>>>> Olga > > > >>>>>> > > > >>>>>> > > > >>>>>> ----- Original > > > >> Message ----- > > > >>>>>> From: Santhosh M S <santhosh_mut...@yahoo.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org>; Olga Natkovich < > > > >>>>> onatkov...@yahoo.com> > > > >>>>>> Cc: > > > >>>>>> Sent: Monday, November 26, 2012 11:49 PM > > > >>>>>> Subject: Re: Our release process > > > >>>>>> > > > >>>>>> Hi Olga, > > > >>>>>> > > > >>>>>> I agree that we cannot guarantee backward compatibility upfront. > > > With > > > >>>>> that knowledge, I am proposing a small modification to your > > proposal. > > > >>> > > > >>>>>> 1. If the trunk or unreleased version is known to be backwards > > > >>>>> compatible then only P1 issues go into the released branch. > > > >>>>>> 2. If the the trunk or unreleased version is known to be > backwards > > > >>>>> incompatible or the release is a long ways off (two quarters?) > then > > > we > > > >>>>> should allow for dot releases on the branch, i.e., P1 and P2 > > issues. > > > >>>>>> > > > >>>>>> I am hoping that should provide an incentive for users to move > to > > a > > > >>>>> higher release and at the same time allow developers to fix > issues > > of > > > >>>>> significance without impacting stability. > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Santhosh > > > >>>>>> > > > >>>>>> > > > >>>>>> ________________________________ > > > >>>>>> From: Olga Natkovich <onatkov...@yahoo.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org> > > > >>>>>> Sent: Monday, November 26, 2012 9:38 AM > > > >>>>>> Subject: Re: Our release process > > > >>>>>> > > > >>>>>> Hi Santhosh, > > > >>>>>> > > > >>>>>> I understand the compatibility issue though I am not sure we can > > > >>>>> guarantee it for all releases upfront but agree that we should > make > > > an > > > >>>>> effort. > > > >>>>>> > > > >>>>>> On the e2e tests, part of the proposal is only do make P1 type > of > > > >>>>> changes to the branch after the initial release so they should be > > > rare. > > > >>>>>> > > > >>>>>> Olga > > > >>> > > > >>>>>> ________________________________ > > > >>>>>> From: Santhosh M S <santhosh_mut...@yahoo.com> > > > >>>>>> To: Olga Natkovich <onatkov...@yahoo.com>; "dev@pig.apache.org" > < > > > >>>>> dev@pig.apache.org> > > > >>>>>> Sent: Monday, November 26, 2012 12:00 AM > > > >>>>>> Subject: 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. > > > >>>>>> > > > >>>>>> Santhosh > > > >>>>>> > > > >>>>>> > > > >>>>>> ________________________________ > > > >>>>>> From: Olga Natkovich <onatkov...@yahoo.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org>; Santhosh M S < > > > >>>>> santhosh_mut...@yahoo.com> > > > >>>>>> 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? > > > >>>>>> > > > >>>>>> Olga > > > >>>>>> > > > >>>>>> > > > >>>>>> ________________________________ > > > >>>>>> From: Santhosh M S <santhosh_mut...@yahoo.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org> > > > >>>>>> 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. > > > >>>>>> > > > >>>>>> Santhosh > > > >>>>>> > > > >>>>>> > > > >>>>>> ________________________________ > > > >>>>>> From: Jonathan Coveney <jcove...@gmail.com> > > > >>>>>> To: "dev@pig.apache.org" <dev@pig.apache.org> > > > >>>>>> 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 > > > >>>>>> it. > > > >>>>>> > > > >>>>>> > > > >>>>>> 2012/11/5 Alan Gates <ga...@hortonworks.com> > > > >>>>>> > > > >>>>>>> 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 <g...@apache.org> > > > >>>>>>>> > > > >>>>>>>>> Hi, > > > >>>>>>>>> > > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga > > > >> Natkovich < > > > >>>>> onatkov...@yahoo.com> > > > >>>>>>>>> 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 > > > >>>>>>>>> > > > >>>>>>>>> Thanks Olga, now I get what you mean. > > > >>>>>>>>> I don't have a strong opinion on > > > >> this. > > > >>>>>>>>> On one hand I see why you don't want to put too many patches > in > > > >> the > > > >>>>>>>>> branches in order to keep things stable. > > > >>>>>>>>> On the other hand when we do a 0.10.x release with x>0 the > > users > > > >>>>> would > > > >>>>>>>>> like to have as many bugs fixed as possible. > > > >>>>>>>>> > > > >>>>>>>>>> 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. > > > >>>>>>>>> > > > >>>>>>>>> I think this makes sense. +1 > > > >>>>>>>>> > > > >>>>>>>>>> Olga > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>>> Cheers, > > > >>>>>>>>> -- > > > >>>>>>>>> Gianmarco > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> *Note that I'm no longer using my Yahoo! email address. Please > email > > > me > > > >> at > > > >>>> billgra...@gmail.com going forward.* > > > >> > > > > > >
