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