9:17 a.m.
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
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com