<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
My $0.02, anything that can be done automated, should be done
without waiting for human intervention. If we can help parallelize
the workflow, even better. The only 'blocker' should be a human
review and verification.<br>
<br>
- Luis<br>
<br>
<div class="moz-cite-prefix">On 05/12/2014 04:04 PM, Anand Avati
wrote:<br>
</div>
<blockquote
cite="mid:CAFboF2ypLcvuXwWYBTgx=ViCxJMAMFahsYRk55==bu9f-TNNvw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, May 12, 2014 at 11:26 AM,
Anand Avati <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:avati@gluster.org" target="_blank">avati@gluster.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div class="">On Mon, May 12, 2014 at 11:21 AM,
Kaleb S. KEITHLEY <span dir="ltr"><<a
moz-do-not-send="true"
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>
<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>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div style="">And yeah, the other reason: if a dev pushes a
series/set of dependent patches, regression needs to run
only on the last one (regression test/voting is cumulative
for the set). Running regression on all the individual
patches (like a smoke test) would be very wasteful, and
tricky to avoid (this was the part which I couldn't solve)</div>
<div style=""><br>
</div>
<div style="">Avati</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<span class="HOEnZb"><font color="#888888">
<div>Avati</div>
</font></span>
<div>
<div class="h5">
<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><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>
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 moz-do-not-send="true"
href="mailto:kkeithle@redhat.com"
target="_blank">kkeithle@redhat.com</a><br>
</div>
<div>
<mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:ndevos@redhat.com"
target="_blank">ndevos@redhat.com</a><br>
<mailto:<a
moz-do-not-send="true"
href="mailto:ndevos@redhat.com"
target="_blank">ndevos@redhat.com</a>><br>
</div>
<div>
<div>
<mailto:<a
moz-do-not-send="true"
href="mailto:ndevos@redhat.com"
target="_blank">ndevos@redhat.com</a>
<mailto:<a moz-do-not-send="true"
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
moz-do-not-send="true"
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>
_________________________________________________
<div><br>
Gluster-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>><br>
</div>
<mailto:<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster."
target="_blank">Gluster-devel@gluster.</a>__org<br>
<mailto:<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>>><br>
<br>
<a moz-do-not-send="true"
href="http://supercolony.gluster."
target="_blank">http://supercolony.gluster.</a>__org/mailman/listinfo/gluster-__devel
<<a moz-do-not-send="true"
href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel"
target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>><br>
<br>
<br>
<br>
<br>
--<br>
Raghavendra G<br>
<br>
<br>
_________________________________________________
<div><br>
Gluster-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>><br>
</div>
<a moz-do-not-send="true"
href="http://supercolony.gluster."
target="_blank">http://supercolony.gluster.</a>__org/mailman/listinfo/gluster-__devel
<<a moz-do-not-send="true"
href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel"
target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>><br>
<br>
<br>
--<br>
<br>
Kaleb<br>
<br>
_________________________________________________
<div><br>
Gluster-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org"
target="_blank">Gluster-devel@gluster.org</a>><br>
</div>
<a moz-do-not-send="true"
href="http://supercolony.gluster."
target="_blank">http://supercolony.gluster.</a>__org/mailman/listinfo/gluster-__devel<br>
<<a moz-do-not-send="true"
href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel"
target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>><br>
<br>
<br>
<span><font color="#888888">
</font></span></blockquote>
<span><font color="#888888">
<br>
-- <br>
<br>
Kaleb<br>
</font></span></blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>