Re: Our release process

[Julien Le Dem <ju...@twitter.com>]

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
<sa...@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 <ju...@twitter.com>
> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> Cc: "billgraham@gmail.com" <bi...@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
> <sa...@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 <bi...@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 <ju...@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
>>> <sa...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
>>> onatkovich@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
>>> > To: Olga Natkovich <on...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
>>> > To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
>>> >> >
>>> >> >> Hi,
>>> >> >>
>>> >> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga Natkovich <
>>> onatkovich@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
>> billgraham@gmail.com going forward.*

Re: Our release process

[Santhosh M S <sa...@yahoo.com>]

Hi Olga,

Daniel has cut the 0.10.1 branch and the release candidate is up for a vote. I think its reasonable to expect such releases where there are a lot of bug fixes. In 0.10.1 there are 48 fixes in all.

The list of bug fixes does not fit the criteria of being having no workaround or failing silently.

Does that work for? 


Santhosh


________________________________
 From: Olga Natkovich <on...@yahoo.com>
To: "dev@pig.apache.org" <de...@pig.apache.org> 
Sent: Monday, December 17, 2012 4:16 PM
Subject: Re: Our release process
 
Hi Jonathan,

I thought I answered your email last week but I just noticed that the answer did not come through.

We tell users that at is coming in the next release. Now that Pig is quite mature and stable, we don't see much of this. Having more frequent releases definitely helps in this respect.

Olga





________________________________
From: Jonathan Coveney <jc...@gmail.com>
To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <on...@yahoo.com> 
Sent: Thursday, December 13, 2012 1:14 PM
Subject: Re: Our release process

Olga,

A related but separate question: what do y'all do when there is a feature
that is finished, but for an upcoming release? ie a feature in trunk, but
not in 0.11 (which, let us assume, is stable).

Jon


2012/12/13 Olga Natkovich <on...@yahoo.com>

> 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 <ju...@twitter.com>
> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> onatkovich@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 <onatkovich@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 <ju...@twitter.com>
> > To: "dev@pig.apache.org" <de...@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 <
> prash1784@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > > > To: Olga Natkovich <on...@yahoo.com>
> > > > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <
> > billgraham@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 <
> > onatkovich@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 <sa...@yahoo.com>
> > > > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > > > >> dev@pig.apache.org>
> > > > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > > > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >> Cc: "billgraham@gmail.com" <bi...@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
> > > > >> <sa...@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 <ju...@twitter.com>
> > > > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >>> Cc: "billgraham@gmail.com" <bi...@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
> > > > >>> <sa...@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 <bi...@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 <
> > julien@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
> > > > >>>>> <sa...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga
> Natkovich <
> > > > >>>>> onatkovich@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > > > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > > > >>>>>>>>
> > > > >>>>>>>>> Hi,
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > > > >> Natkovich <
> > > > >>>>> onatkovich@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
> > > > >>>> billgraham@gmail.com going forward.*
> > > > >>
> > > >
> > >
> >
>
>

Re: Our release process

[Olga Natkovich <on...@yahoo.com>]

Hi Jonathan,

I thought I answered your email last week but I just noticed that the answer did not come through.

We tell users that at is coming in the next release. Now that Pig is quite mature and stable, we don't see much of this. Having more frequent releases definitely helps in this respect.

Olga





________________________________
From: Jonathan Coveney <jc...@gmail.com>
To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <on...@yahoo.com> 
Sent: Thursday, December 13, 2012 1:14 PM
Subject: Re: Our release process

Olga,

A related but separate question: what do y'all do when there is a feature
that is finished, but for an upcoming release? ie a feature in trunk, but
not in 0.11 (which, let us assume, is stable).

Jon


2012/12/13 Olga Natkovich <on...@yahoo.com>

> 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 <ju...@twitter.com>
> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> onatkovich@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 <onatkovich@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 <ju...@twitter.com>
> > To: "dev@pig.apache.org" <de...@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 <
> prash1784@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > > > To: Olga Natkovich <on...@yahoo.com>
> > > > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <
> > billgraham@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 <
> > onatkovich@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 <sa...@yahoo.com>
> > > > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > > > >> dev@pig.apache.org>
> > > > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > > > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >> Cc: "billgraham@gmail.com" <bi...@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
> > > > >> <sa...@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 <ju...@twitter.com>
> > > > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >>> Cc: "billgraham@gmail.com" <bi...@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
> > > > >>> <sa...@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 <bi...@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 <
> > julien@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
> > > > >>>>> <sa...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga
> Natkovich <
> > > > >>>>> onatkovich@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > > > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > > > >>>>>>>>
> > > > >>>>>>>>> Hi,
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > > > >> Natkovich <
> > > > >>>>> onatkovich@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
> > > > >>>> billgraham@gmail.com going forward.*
> > > > >>
> > > >
> > >
> >
>
>

Re: Our release process

[Jonathan Coveney <jc...@gmail.com>]

Olga,

A related but separate question: what do y'all do when there is a feature
that is finished, but for an upcoming release? ie a feature in trunk, but
not in 0.11 (which, let us assume, is stable).

Jon


2012/12/13 Olga Natkovich <on...@yahoo.com>

> 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 <ju...@twitter.com>
> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> onatkovich@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 <onatkovich@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 <ju...@twitter.com>
> > To: "dev@pig.apache.org" <de...@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 <
> prash1784@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > > > To: Olga Natkovich <on...@yahoo.com>
> > > > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <
> > billgraham@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 <
> > onatkovich@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 <sa...@yahoo.com>
> > > > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > > > >> dev@pig.apache.org>
> > > > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > > > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >> Cc: "billgraham@gmail.com" <bi...@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
> > > > >> <sa...@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 <ju...@twitter.com>
> > > > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > > >>> Cc: "billgraham@gmail.com" <bi...@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
> > > > >>> <sa...@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 <bi...@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 <
> > julien@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
> > > > >>>>> <sa...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga
> Natkovich <
> > > > >>>>> onatkovich@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > > > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > > > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > > > >>>>>>>>
> > > > >>>>>>>>> Hi,
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > > > >> Natkovich <
> > > > >>>>> onatkovich@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
> > > > >>>> billgraham@gmail.com going forward.*
> > > > >>
> > > >
> > >
> >
>
>

Re: Our release process

[Olga Natkovich <on...@yahoo.com>]

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 <ju...@twitter.com>
To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <on...@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 <on...@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 <ju...@twitter.com>
> To: "dev@pig.apache.org" <de...@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 <prash1784@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > > To: Olga Natkovich <on...@yahoo.com>
> > > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <
> billgraham@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 <
> onatkovich@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 <sa...@yahoo.com>
> > > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > > >> dev@pig.apache.org>
> > > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > >> Cc: "billgraham@gmail.com" <bi...@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
> > > >> <sa...@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 <ju...@twitter.com>
> > > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > >>> Cc: "billgraham@gmail.com" <bi...@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
> > > >>> <sa...@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 <bi...@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 <
> julien@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
> > > >>>>> <sa...@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> > > >>>>> onatkovich@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > > >>>>>>>>
> > > >>>>>>>>> Hi,
> > > >>>>>>>>>
> > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > > >> Natkovich <
> > > >>>>> onatkovich@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
> > > >>>> billgraham@gmail.com going forward.*
> > > >>
> > >
> >
>

Re: Our release process

[Julien Le Dem <ju...@twitter.com>]

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 <on...@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 <ju...@twitter.com>
> To: "dev@pig.apache.org" <de...@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 <prash1784@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > > To: Olga Natkovich <on...@yahoo.com>
> > > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <
> billgraham@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 <
> onatkovich@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 <sa...@yahoo.com>
> > > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > > >> dev@pig.apache.org>
> > > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > >> Cc: "billgraham@gmail.com" <bi...@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
> > > >> <sa...@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 <ju...@twitter.com>
> > > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > > >>> Cc: "billgraham@gmail.com" <bi...@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
> > > >>> <sa...@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 <bi...@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 <
> julien@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
> > > >>>>> <sa...@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> > > >>>>> onatkovich@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > > >>>>>>>>
> > > >>>>>>>>> Hi,
> > > >>>>>>>>>
> > > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > > >> Natkovich <
> > > >>>>> onatkovich@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
> > > >>>> billgraham@gmail.com going forward.*
> > > >>
> > >
> >
>

Re: Our release process

[Olga Natkovich <on...@yahoo.com>]

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 <ju...@twitter.com>
To: "dev@pig.apache.org" <de...@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 <pr...@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > To: Olga Natkovich <on...@yahoo.com>
> > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <billgraham@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 <onatkovich@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 <sa...@yahoo.com>
> > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > >> dev@pig.apache.org>
> > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > >> Cc: "billgraham@gmail.com" <bi...@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
> > >> <sa...@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 <ju...@twitter.com>
> > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > >>> Cc: "billgraham@gmail.com" <bi...@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
> > >>> <sa...@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 <bi...@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 <julien@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
> > >>>>> <sa...@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> > >>>>> onatkovich@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > >>>>>>>>
> > >>>>>>>>> Hi,
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > >> Natkovich <
> > >>>>> onatkovich@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
> > >>>> billgraham@gmail.com going forward.*
> > >>
> >
>

Re: Our release process

[Julien Le Dem <ju...@twitter.com>]

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 <pr...@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.jurney@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 <on...@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 <ju...@twitter.com>
> > > To: Olga Natkovich <on...@yahoo.com>
> > > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <billgraham@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 <onatkovich@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 <sa...@yahoo.com>
> > >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> > >> dev@pig.apache.org>
> > >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> > >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > >> Cc: "billgraham@gmail.com" <bi...@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
> > >> <sa...@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 <ju...@twitter.com>
> > >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > >>> Cc: "billgraham@gmail.com" <bi...@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
> > >>> <sa...@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 <bi...@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 <julien@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
> > >>>>> <sa...@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> > >>>>> onatkovich@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> > >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> > >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> > >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> > >>>>>>>>
> > >>>>>>>>> Hi,
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> > >> Natkovich <
> > >>>>> onatkovich@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
> > >>>> billgraham@gmail.com going forward.*
> > >>
> >
>

Re: Our release process

[Prashant Kommireddi <pr...@gmail.com>]

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 <ru...@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 <on...@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 <ju...@twitter.com>
> > To: Olga Natkovich <on...@yahoo.com>
> > Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> santhosh_muthur@yahoo.com>; "billgraham@gmail.com" <bi...@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 <onatkovich@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 <sa...@yahoo.com>
> >> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> >> dev@pig.apache.org>
> >> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> >> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> >> Cc: "billgraham@gmail.com" <bi...@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
> >> <sa...@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 <ju...@twitter.com>
> >>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> >>> Cc: "billgraham@gmail.com" <bi...@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
> >>> <sa...@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 <bi...@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 <ju...@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
> >>>>> <sa...@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 <on...@yahoo.com>
> >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> >>>>> onatkovich@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 <on...@yahoo.com>
> >>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> >>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
> >>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>>>> santhosh_muthur@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 <sa...@yahoo.com>
> >>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> >>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> >> Natkovich <
> >>>>> onatkovich@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
> >>>> billgraham@gmail.com going forward.*
> >>
>

Re: Our release process

[Russell Jurney <ru...@gmail.com>]

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 <on...@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 <ju...@twitter.com>
> To: Olga Natkovich <on...@yahoo.com>
> Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <sa...@yahoo.com>; "billgraham@gmail.com" <bi...@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 <on...@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 <sa...@yahoo.com>
>> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
>> dev@pig.apache.org>
>> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
>> Cc: "billgraham@gmail.com" <bi...@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
>> <sa...@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 <ju...@twitter.com>
>>> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
>>> Cc: "billgraham@gmail.com" <bi...@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
>>> <sa...@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 <bi...@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 <ju...@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
>>>>> <sa...@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 <on...@yahoo.com>
>>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>>>> santhosh_muthur@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 <sa...@yahoo.com>
>>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
>>>>> onatkovich@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 <on...@yahoo.com>
>>>>>> To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
>>>>>> To: Olga Natkovich <on...@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 <on...@yahoo.com>
>>>>>> To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>>>> santhosh_muthur@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 <sa...@yahoo.com>
>>>>>> To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
>>>>>> To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Mon, Nov 5, 2012 at 10:48 AM, Olga
>> Natkovich <
>>>>> onatkovich@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
>>>> billgraham@gmail.com going forward.*
>>

Re: Our release process

[Olga Natkovich <on...@yahoo.com>]

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 <ju...@twitter.com>
To: Olga Natkovich <on...@yahoo.com> 
Cc: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <sa...@yahoo.com>; "billgraham@gmail.com" <bi...@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 <on...@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 <sa...@yahoo.com>
> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> dev@pig.apache.org>
> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> Cc: "billgraham@gmail.com" <bi...@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
> <sa...@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 <ju...@twitter.com>
> > To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > Cc: "billgraham@gmail.com" <bi...@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
> > <sa...@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 <bi...@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 <ju...@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
> >>> <sa...@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>> santhosh_muthur@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 <sa...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> >>> onatkovich@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> >>> > To: Olga Natkovich <on...@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>> santhosh_muthur@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 <sa...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> >>> >> >
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> Natkovich <
> >>> onatkovich@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
> >> billgraham@gmail.com going forward.*
>
>

Re: Our release process

[Julien Le Dem <ju...@twitter.com>]

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 <on...@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 <sa...@yahoo.com>
> *To:* Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <
> dev@pig.apache.org>
> *Cc:* "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> Cc: "billgraham@gmail.com" <bi...@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
> <sa...@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 <ju...@twitter.com>
> > To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> > Cc: "billgraham@gmail.com" <bi...@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
> > <sa...@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 <bi...@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 <ju...@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
> >>> <sa...@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>> santhosh_muthur@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 <sa...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
> >>> onatkovich@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
> >>> > To: Olga Natkovich <on...@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 <on...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
> >>> santhosh_muthur@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 <sa...@yahoo.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
> >>> > To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
> >>> >> >
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga
> Natkovich <
> >>> onatkovich@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
> >> billgraham@gmail.com going forward.*
>
>

Re: Our release process

[Olga Natkovich <on...@yahoo.com>]

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 <sa...@yahoo.com>
To: Julien Le Dem <ju...@twitter.com>; "dev@pig.apache.org" <de...@pig.apache.org> 
Cc: "billgraham@gmail.com" <bi...@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 <ju...@twitter.com>
To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com> 
Cc: "billgraham@gmail.com" <bi...@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
<sa...@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 <ju...@twitter.com>
> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> Cc: "billgraham@gmail.com" <bi...@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
> <sa...@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 <bi...@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 <ju...@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
>>> <sa...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
>>> onatkovich@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
>>> > To: Olga Natkovich <on...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
>>> > To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
>>> >> >
>>> >> >> Hi,
>>> >> >>
>>> >> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga
Natkovich <
>>> onatkovich@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
>> billgraham@gmail.com going forward.*

Re: Our release process

[Santhosh M S <sa...@yahoo.com>]

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 <ju...@twitter.com>
To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com> 
Cc: "billgraham@gmail.com" <bi...@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
<sa...@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 <ju...@twitter.com>
> To: dev@pig.apache.org; Santhosh M S <sa...@yahoo.com>
> Cc: "billgraham@gmail.com" <bi...@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
> <sa...@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 <bi...@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 <ju...@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
>>> <sa...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Olga Natkovich <
>>> onatkovich@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <sa...@yahoo.com>
>>> > To: Olga Natkovich <on...@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 <on...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@pig.apache.org>; Santhosh M S <
>>> santhosh_muthur@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 <sa...@yahoo.com>
>>> > To: "dev@pig.apache.org" <de...@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 <jc...@gmail.com>
>>> > To: "dev@pig.apache.org" <de...@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 <gd...@apache.org>
>>> >> >
>>> >> >> Hi,
>>> >> >>
>>> >> >> On Mon, Nov 5, 2012 at 10:48 AM, Olga
 Natkovich <
>>> onatkovich@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
>> billgraham@gmail.com going forward.*