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.
-Lala _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
