+1 On Fri, May 2, 2014 at 3:37 AM, Niels de Vos <ndevos@xxxxxxxxxx> 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@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
