<div dir="ltr">It is much better to code review after regression tests pass (premise being human eye time is more precious than build server run time)<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 12, 2014 at 10:53 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"><top-post><br>
How about also an auto run of regression at +1 or +2 code review?<br>
</top-post><div class=""><br>
<br>
On 05/12/2014 01:49 PM, Raghavendra G wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
+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></div><div><div class="h5">
<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 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 running:<br>
> ><br>
> >1. upon patch submission, next to smoke (compile+posix) tests<br>
> >2. rpm.t in the regression tests framework<br>
> ><br>
> >Both have their own advantages, and both cover a little different<br>
> >use-case.<br>
> ><br>
> >Notes and observations for 1:<br>
> ><br>
> > The advantage of (1) is that the built rpm-packages 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 patches need<br>
several<br>
> > revisions before they get accepted, each new revision gets new<br>
> > packages build (takes time for each patch submission). I do<br>
not know<br>
> > how long these packages are kept, or when they are deleted.<br>
> ><br>
> > Building is done for EPEL-6 and Fedora (exact version unclear<br>
to me).<br>
> ><br>
> ><br>
> >Notes and observations for 2:<br>
> ><br>
> > Building is only done when there are changes related to the<br>
packaging.<br>
> > When there are only changes in source code or 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. The resulting<br>
> > packages are deleted automatically and can not be downloaded.<br>
> ><br>
> > When writing rpm.t, we decided that building for 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 much with the<br>
> > packaging.<br>
> ><br>
> ><br>
> >Suggestion for improving the current duplicate package building:<br>
> ><br>
> > Building packages takes a lot of resources. It does not seem<br>
efficient<br>
> > to me to build packages for two EPEL-6 and Fedora for each patch<br>
> > submission. This takes additional time for a check (smoke.sh)<br>
that is<br>
> > tried to keep quick. I also doubt that many of the generated<br>
packages<br>
> > are actually used by anyone. Most developers (hopefully) test<br>
their<br>
> > changes before submitting the patch(es) to Gerrit.<br>
> ><br>
> > There is a definite need to verify that the packaging still<br>
works, it<br>
> > helps to catch packaging errors as early as possible. Testing<br>
each<br>
> > patch submission might be overkill. Creating packages as part<br>
of the<br>
> > regression tests (and make them available) might be too late,<br>
> > regression testing tends to take quite long.<br>
> ><br>
> > From my understanding, the only users that are interested in<br>
these<br>
> > very early packages, are the QA folks. We definitely want<br>
them to test<br>
> > whatever the developers change, so we should accommodate them<br>
as much<br>
> > as possible.<br>
> ><br>
> > After some discussion, Pranith tossed the idea about 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 packages when<br>
at least<br>
> > one +1 has been given on a change. Alternatively, it 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 current<br>
building<br>
> > jobs.<br>
> ><br>
> ><br>
> >Ideas and further discussions are very much welcome, 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 we also<br>
> plan for "deb" (Debian packages) too? As we have quite a few users<br>
> using Debian/Ubuntu distribution.<br>
<br>
Yes, .deb would be a next step, probably followed by NetBSD and OSX.<br>
<br>
Any objections if the current devrpms jobs (upon patch submission) will<br>
be removed, and inserted at a +1 Code-Review or +1 Verified? Any<br>
volunteers that know Jenkins and its Gerrit integration well enough to<br>
make this happen?<br>
<br>
I have no idea how to create Jenkins jobs that can create RPMs, probably<br>
Luis can help with that.<br>
<br>
Thanks,<br>
Niels<br>
______________________________<u></u>_________________<br>
Gluster-devel mailing list<br></div></div>
<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>><div class=""><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>
<br>
<br>
--<br>
Raghavendra G<br>
<br>
<br>
______________________________<u></u>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><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>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
<br>
Kaleb</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><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>
</div></div></blockquote></div><br></div></div>