Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Pig >> mail # dev >> Our release process


+
Olga Natkovich 2012-11-02, 22:58
+
Alan Gates 2012-11-03, 03:19
+
Gianmarco De Francisci Mo... 2012-11-03, 17:20
+
Olga Natkovich 2012-11-05, 01:17
+
Gianmarco De Francisci Mo... 2012-11-05, 18:37
+
Olga Natkovich 2012-11-05, 18:48
+
Gianmarco De Francisci Mo... 2012-11-05, 19:34
+
Jonathan Coveney 2012-11-06, 00:53
+
Alan Gates 2012-11-06, 02:12
+
Jonathan Coveney 2012-11-07, 02:34
+
Santhosh M S 2012-11-19, 23:48
+
Olga Natkovich 2012-11-26, 01:56
+
Santhosh M S 2012-11-26, 08:00
+
Olga Natkovich 2012-11-26, 17:38
+
Santhosh M S 2012-11-30, 07:16
Copy link to this message
-
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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; Santhosh M S <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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
+
Santhosh M S 2012-12-01, 07:46
+
Olga Natkovich 2012-12-04, 20:46
+
Julien Le Dem 2012-12-07, 23:54
+
Olga Natkovich 2012-12-10, 23:22
+
Russell Jurney 2012-12-11, 03:03
+
Prashant Kommireddi 2012-12-11, 16:54
+
Julien Le Dem 2012-12-12, 18:26
+
Olga Natkovich 2012-12-12, 19:08
+
Julien Le Dem 2012-12-13, 00:54
+
Olga Natkovich 2012-12-13, 21:04
+
Jonathan Coveney 2012-12-13, 21:14
+
Olga Natkovich 2012-12-18, 00:16
+
Santhosh M S 2012-12-23, 01:56
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB