<div dir="ltr">+1 to create RPMs when there is atleast a +1 on code review.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 5, 2014 at 8:06 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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 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 several<br>
> > revisions before they get accepted, each new revision gets new<br>
> > packages build (takes time for each patch submission). I do 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 to me).<br>
> ><br>
> ><br>
> >Notes and observations for 2:<br>
> ><br>
> > Building is only done when there are changes related to the packaging.<br>
> > When there are only changes in source code or documentation, 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 little<br>
> > dangerous, there are the occasional incompatible changes 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 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) that is<br>
> > tried to keep quick. I also doubt that many of the generated packages<br>
> > are actually used by anyone. Most developers (hopefully) test their<br>
> > changes before submitting the patch(es) to Gerrit.<br>
> ><br>
> > There is a definite need to verify that the packaging still works, it<br>
> > helps to catch packaging errors as early as possible. Testing each<br>
> > patch submission might be overkill. Creating packages as part 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 these<br>
> > very early packages, are the QA folks. We definitely want them to test<br>
> > whatever the developers change, so we should accommodate them as much<br>
> > as possible.<br>
> ><br>
> > After some discussion, Pranith tossed the idea about building packages<br>
> > when at lease some review of the change has been done. I think this is<br>
> > a great idea! So, I'd like to propose building packages when 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 builds the<br>
> > packages earlier already. This can then replace both current 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>
</div></div>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>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Raghavendra G<br>
</div>