[Gluster-devel] Automatically building RPMs upon patch submission?

[Harshavardhana]

+1

On Fri, May 2, 2014 at 3:37 AM, Niels de Vos <ndevos at redhat.com> 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
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel



-- 
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes