Hi, Le 05/02/2016 15:06, Gabriele Cerami a écrit :
> If the patches are never merged how do you know they don't create > conflicts, what is the merge base of the patches ? patches are never > rebased on each other but only to a common base ? In the RPM Factory context let's say we have a project "A" packaged for Liberty. "A" is packaged at version 1.0 and 2 patches are needed. Then we have liberty-patches branch reset on tag 1.0 and : - patch 1 (gerrit review) has liberty-patches HEAD as parent - patch 2 (gerrit review) has patch 1 as parent. So the base is liberty-patches HEAD (or the tag 1.0). If you "git review -d <gerrit_id of patch 2>" -> you fetch tag 1.0 + p1 + p2 already applied. > Since SF is package-centered, I know this is less relevant, because all > the patches end in the package at some point, and you test that. >> About the master version of RDO, AFAIK yes Delorean does not use any >> patches when >> trying to use rpm-master distgit to test the packaging against each >> upstream changes >> so there is not need to run unit test in that case IMO. > > Unit tests, no. Acceptance tests, yes. Upstream CI will never be enough > because all the projects always download bleeding edge versions for > dependencies that may not be present, or have different version in the > distro packages. Yes sure if a project or a puppet module embed a functional test suite (like Beaker for a puppet module) then we should definitely run them each time a change is proposed again a distgit. For instance when a maintainer, of one of the future splited OPM, proposes on new change (Gerrit review) on the distgit then the RPM of the puppet module is built and is installed on a fresh test node (dependencies, configured in the RPM, are installed) and then the acceptance tests (Beaker) will run. I think we can easily give an adequate feedback to the packager especially dependencies issues. After all this is one of the job of a package maintainer -> dealing with package dependencies :) In the context of RPM Factory, note this behavior can only work for stable branches rdo-liberty, "rdo-mitaka', not with rpm-master. >> 2. until then, we can just use our own mirrors instead of upstream >> 3. depending how much time, it'll take, it would be worth considering >> having vanilla puppet modules packages available for testing >> Moreover associated w/ delorean, it will help us to catch glitches as >> soon as puppet modules gets broken. > > One of the big things I'm trying to undestand here, is how much test do > we want, on OPM and in general. > OPM-CI is currently trying to run tests after each upstream change is > merged, but before the same change is merged downstream. After this, a > package may be created and tested with the rest of the puppet modules, > but testing before merge catches errors very early in the chain, and we > immediately know which package caused the havoc, because we are testing > only one, not the entire set of modules at once. Should splited OPM be managed the way as the other RDO packages ? I mean Delorean uses the rpm-master to test packaging of each OPM packages and the CI tags the repo as "current-passed-ci" when validation jobs pass. > > Fabien, can we begin to transfer gitnetics jobs to SF ? I'd like to > know what happens when the two meet. > Yes sure we can discuss how to test both together. Let's ping me on IRC. Cheers, Fabien > _______________________________________________ > Rdo-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: [email protected] > _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
