[Gluster-devel] Automatically building RPMs upon patch submission?

[Anand Avati]

On Mon, May 12, 2014 at 7:20 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Anand Avati" <avati at gluster.org>
> > To: "Justin Clift" <justin at gluster.org>
> > Cc: gluster-devel at gluster.org
> > Sent: Tuesday, May 13, 2014 5:50:07 AM
> > Subject: Re: [Gluster-devel] Automatically building RPMs upon patch
> submission?
> >
> >
> >
> >
> > On Mon, May 12, 2014 at 5:16 PM, Justin Clift < justin at gluster.org >
> wrote:
> >
> >
> >
> > On 13/05/2014, at 1:00 AM, Anand Avati wrote:
> > > On Mon, May 12, 2014 at 4:39 PM, Justin Clift < justin at gluster.org >
> wrote:
> > > On 13/05/2014, at 12:27 AM, Anand Avati wrote:
> > > <snip>
> > > > http://build.gluster.org/job/regression/build - key in the gerrit
> patch
> > > > number for the CHANGE_ID field, and click 'Build'.
> > >
> > > Doesn't that just apply the given change to HEAD of its
> > > associated branch? eg it won't apply dependent commits
> > > first?
> > >
> > > No, this is just for jenkins to run tests and vote on gerrit. Applying
> a
> > > change into HEAD is done by sub/maintainers having commit rights to the
> > > project in Gerrit. However Gerrit prevents even a maintainer from
> > > committing until there is +2 code review vote and +1 verified vote (no
> > > matter who votes - Jenkins or someone else)
> >
> > Heh, bad wording. Was meaning "doesn't that just test the given
> > patch applied to HEAD for it's associated branch?". Wasn't meaning
> > actually committing it back to the repo. ;)
> >
> > Thinking about it more, if we're just testing _too many_ things
> > it's likely only a problem short term. When we get the regression
> > testing parallelised (soon), then it shouldn't really matter much.
> >
> > Ah, I see what you meant. Specifying a gerrit patch# as CHANGE_ID will
> apply
> > that patch and all its dependent (unmerged yet) gerrit patches on top of
> > HEAD and run the tests. If test fails, then the entire patch set is voted
> > -1, not just the CHANGE_ID specified.
>
> Avati/Justin
> If we are going to start the regression after the smoketest completes,
> most likely all the dependent/needed-by patches are submitted by then. So
> just as we try to figure out the 'depends on' patches won't we be able to
> figure out 'needed by' patches? If we can, then the only problem is to
> figure-out if we had already launched a regression test for that 'top'
> patch to prevent triggering duplicate regressions. If we want to be more
> precise we can even wait for smoketests of the whole patch set to complete
> before triggering the regression.
>

Git being a DAG (upward), is trivial to get parents transitively. There is
no natural way to get the immediate child commits of git, at least they are
not indexed by design. We will need a way to look into gerrit's 'needed by'
field, not sure how easy/trivial that is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140512/353b76f6/attachment-0002.html>