<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 12, 2014 at 11:21 AM, Kaleb S. KEITHLEY <span dir="ltr"><<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Then maybe we should run regression tests on check-in. I'm getting tired of queuing up regression tests. (And I know I'm not the only one doing it.)<br>
<br>
Or run them after they pass the smoke test,<br>
<br>
Or....</blockquote><div><br></div><div>If we can make regression test trigger automatically, conditional on smoke-test passing, that would be great. Last time I checked I couldn't figure how to (did not look very deep) and left it manual trigger.</div>
<div><br></div><div>Avati</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
On 05/12/2014 02:17 PM, Anand Avati wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
It is much better to code review after regression tests pass (premise<br>
being human eye time is more precious than build server run time)<br>
<br>
<br>
On Mon, May 12, 2014 at 10:53 AM, Kaleb S. KEITHLEY <<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a><br></div><div class="">
<mailto:<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>>> wrote:<br>
<br>
<top-post><br>
How about also an auto run of regression at +1 or +2 code review?<br>
</top-post><br>
<br>
<br>
On 05/12/2014 01:49 PM, Raghavendra G wrote:<br>
<br>
+1 to create RPMs when there is atleast a +1 on code review.<br>
<br>
<br>
On Mon, May 5, 2014 at 8:06 PM, Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a><br>
<mailto:<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>><br></div><div><div class="h5">
<mailto:<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a> <mailto:<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>>>> wrote:<br>
<br>
On Mon, May 05, 2014 at 07:13:14PM +0530, Lalatendu Mohanty<br>
wrote:<br>
> On 05/02/2014 04:07 PM, Niels de Vos wrote:<br>
> >Hi all,<br>
> ><br>
> >at the moment we have some duplicate RPM-building tests<br>
running:<br>
> ><br>
> >1. upon patch submission, next to smoke (compile+posix)<br>
tests<br>
> >2. rpm.t in the regression tests framework<br>
> ><br>
> >Both have their own advantages, and both cover a little<br>
different<br>
> >use-case.<br>
> ><br>
> >Notes and observations for 1:<br>
> ><br>
> > The advantage of (1) is that the built rpm-packages<br>
are made<br>
available<br>
> > for downloading, and users can test the change easier.<br>
> ><br>
> > It is unclear to me how often this is used, many<br>
patches need<br>
several<br>
> > revisions before they get accepted, each new<br>
revision gets new<br>
> > packages build (takes time for each patch<br>
submission). I do<br>
not know<br>
> > how long these packages are kept, or when they are<br>
deleted.<br>
> ><br>
> > Building is done for EPEL-6 and Fedora (exact<br>
version unclear<br>
to me).<br>
> ><br>
> ><br>
> >Notes and observations for 2:<br>
> ><br>
> > Building is only done when there are changes related<br>
to the<br>
packaging.<br>
> > When there are only changes in source code or<br>
documentation,<br>
there is<br>
> > no need to try and build the rpms (saves ca. 5 minutes).<br>
> ><br>
> > The packages are build for EPEL-5 and EPEL-6 only.<br>
The resulting<br>
> > packages are deleted automatically and can not be<br>
downloaded.<br>
> ><br>
> > When writing rpm.t, we decided that building for<br>
Fedora was a<br>
little<br>
> > dangerous, there are the occasional incompatible changes<br>
introduced.<br>
> > We also don't want to bother every developer too<br>
much with the<br>
> > packaging.<br>
> ><br>
> ><br>
> >Suggestion for improving the current duplicate package<br>
building:<br>
> ><br>
> > Building packages takes a lot of resources. It does<br>
not seem<br>
efficient<br>
> > to me to build packages for two EPEL-6 and Fedora<br>
for each patch<br>
> > submission. This takes additional time for a check<br>
(smoke.sh)<br>
that is<br>
> > tried to keep quick. I also doubt that many of the<br>
generated<br>
packages<br>
> > are actually used by anyone. Most developers<br>
(hopefully) test<br>
their<br>
> > changes before submitting the patch(es) to Gerrit.<br>
> ><br>
> > There is a definite need to verify that the<br>
packaging still<br>
works, it<br>
> > helps to catch packaging errors as early as<br>
possible. Testing<br>
each<br>
> > patch submission might be overkill. Creating<br>
packages as part<br>
of the<br>
> > regression tests (and make them available) might be<br>
too late,<br>
> > regression testing tends to take quite long.<br>
> ><br>
> > From my understanding, the only users that are<br>
interested in<br>
these<br>
> > very early packages, are the QA folks. We definitely<br>
want<br>
them to test<br>
> > whatever the developers change, so we should<br>
accommodate them<br>
as much<br>
> > as possible.<br>
> ><br>
> > After some discussion, Pranith tossed the idea about<br>
building<br>
packages<br>
> > when at lease some review of the change has been done. I<br>
think this is<br>
> > a great idea! So, I'd like to propose building<br>
packages when<br>
at least<br>
> > one +1 has been given on a change. Alternatively, it<br>
should be<br>
> > possible for the QA people to submit a Jenkins job that<br>
builds the<br>
> > packages earlier already. This can then replace both<br>
current<br>
building<br>
> > jobs.<br>
> ><br>
> ><br>
> >Ideas and further discussions are very much welcome,<br>
thanks,<br>
> >Niels<br>
> ><br>
> >Related: <a href="http://review.gluster.org/7610" target="_blank">http://review.gluster.org/7610</a><br>
><br>
> I am not sure if we have a Jenkins job to create RPM for a<br>
> particular change-id. if not, we should have one. Should<br>
we also<br>
> plan for "deb" (Debian packages) too? As we have quite<br>
a few users<br>
> using Debian/Ubuntu distribution.<br>
<br>
Yes, .deb would be a next step, probably followed by NetBSD<br>
and OSX.<br>
<br>
Any objections if the current devrpms jobs (upon patch<br>
submission) will<br>
be removed, and inserted at a +1 Code-Review or +1<br>
Verified? Any<br>
volunteers that know Jenkins and its Gerrit integration<br>
well enough to<br>
make this happen?<br>
<br>
I have no idea how to create Jenkins jobs that can create<br>
RPMs, probably<br>
Luis can help with that.<br>
<br>
Thanks,<br>
Niels<br></div></div>
______________________________<u></u>___________________<div class=""><br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<u></u>org</a>><br></div>
<mailto:<a href="mailto:Gluster-devel@gluster." target="_blank">Gluster-devel@gluster.</a><u></u>__org<br>
<mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<u></u>org</a>>><br>
<br>
<a href="http://supercolony.gluster." target="_blank">http://supercolony.gluster.</a>__<u></u>org/mailman/listinfo/gluster-_<u></u>_devel <<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.<u></u>org/mailman/listinfo/gluster-<u></u>devel</a>><br>
<br>
<br>
<br>
<br>
--<br>
Raghavendra G<br>
<br>
<br>
______________________________<u></u>___________________<div class=""><br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<u></u>org</a>><br></div>
<a href="http://supercolony.gluster." target="_blank">http://supercolony.gluster.</a>__<u></u>org/mailman/listinfo/gluster-_<u></u>_devel <<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.<u></u>org/mailman/listinfo/gluster-<u></u>devel</a>><br>
<br>
<br>
--<br>
<br>
Kaleb<br>
<br>
______________________________<u></u>___________________<div class=""><br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<u></u>org</a>><br></div>
<a href="http://supercolony.gluster." target="_blank">http://supercolony.gluster.</a>__<u></u>org/mailman/listinfo/gluster-_<u></u>_devel<br>
<<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.<u></u>org/mailman/listinfo/gluster-<u></u>devel</a>><br>
<br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
<br>
Kaleb<br>
</font></span></blockquote></div><br></div></div>