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 >> Re: Our release process


+
Santhosh M S 2012-11-30, 07:16
+
Julien Le Dem 2012-12-01, 01:37
+
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
Copy link to this message
-
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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]
> >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 <
> [EMAIL PROTECTED]
> > >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 <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > > > To: Olga Natkovich <[EMAIL PROTECTED]>
> > > > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Santhosh M S <
> > > [EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <
> [EMAIL PROTECTED]
> > >
> > > > 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
+
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