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 <kkeithle@xxxxxxxxxx> 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 <ndevos@xxxxxxxxxxGluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@gluster.org><mailto:ndevos@xxxxxxxxxx>> 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
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
--
Raghavendra G
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
--
Kaleb
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
