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 Threaded View
Pig >> mail # dev >> Our release process


Hi,

I agree with what Alan says and I like his proposal.
However, to make it feasible, we need to make jenkins builds stable,
otherwise a real problem introduced by a patch might be lost in the
hundreds of failures due to clover licenses, minicluster issues, etc...

I don't like too much making jenkins post to jira the results of the build
after a patch is committed, as it pollutes the jira itself, however in this
case it might be a good way to promote developer responsibility. Is it
possible to activate this only for branches?

Cheers,
--
Gianmarco

On Fri, Nov 2, 2012 at 8:19 PM, Alan Gates <[EMAIL PROTECTED]> wrote:

> I am all for maintaining stability of branches, and the trunk, as everyone
> benefits from it.  But I do not think this means we should limit bug fixing
> in the branches to only critical issues.  As Pig gets more users we have
> more and more people on older branches who will want fixes for bugs without
> dealing with bigger version changes.  So I am not in favor of limiting
> checkins to branches to P1 issues.
>
> What if we maintain stability on the branches by quickly reverting any
> patches that break the build, the unit tests, or the e2e tests?  This
> allows us to move forward with bug fix versions, it allows those who depend
> on branch stability (which I suspect is everyone in the distribution
> business plus everyone rolling their own Pig), and it should promote
> developer responsibility (no one likes having their patches reverted).
>
> Alan.
>
> On Nov 2, 2012, at 3:58 PM, Olga Natkovich wrote:
>
> > Hi guys,
> >
> > Mid next year, we agreed on a release process documented in this thread:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg04172.html.
> >
> > Since then, we have not really followed either of its two rules:
> >
> > (1) Frequent (every 3 month releases)
> > (2) Branch stability (only P1 issues on the branch).
> >
> > So I wanted to revisit our release procedure to make sure we have one
> that we can actually follow.
> >
> > For us at Yahoo, branch stability is very important since we release all
> the patches directly from the branch. If we can't rely on the fact that
> only critical fixes go in, we will need to resort to git branches that will
> make the whole process very comberson because we now need to hand pick
> patches from the apache branch and port them onto our private branch. I
> would imaging that others using Pig in production would have similar issues.
> >
> > Olga
> >
> >
> > Olga
>
>
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