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

[Niels de Vos]

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