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 <ga...@hortonworks.com> 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/dev@pig.apache.org/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
>
>

Reply via email to