Re: [Rdo-list] [Softwarefactory-dev] Gitnetics integration, or how can we automate upstream changes polling

Hi, Apologies for cross-posting. I don't like replies branching, so I'm answering to all replies in one big email. On Thu, 2016-02-04 at 11:30 +0100, Fabien Boucher wrote: 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 ? 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. 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. not on top, and not unit tests. Gitnetics, in one of its mode, merges clean upstream branch, with local patches branch, and create a third branch that is the merge between the two. On the other mode, just proposes (without merging) backports to a -patches branch. Currently OPM-CI is running upstream acceptance tests, but forcing modules to use dependencies available from distro packages, then something called stability tests, to see if modules are deploying stuff like we expect them do to. (usually catch when a variable changes its default) This is exactly what happens, except gitnetics can run on both periodic jobs and triggered by gerrit event, and in its "lock and backports" mode there is no automatic merging, all is tested in temporary branch and only if unit tests pass, the change is proposed as backport to the branch. If something fails, a developer may just add DISCARD as comment to the paused review, and everything will be canceled. On Thu, 2016-02-04 at 12:31 +0100, Haïkel wrote: Not having downstream patches is a great goal to have, not having a backup plan for that one time that is really needed and you don't have the infrastructure to handle it, is a bad move 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. I think everyone here is talking about cherry-picking in -patches branches. Main branches downstream are always an exact copy of the upstream equivalent branch Can you be more specific in what you consider upstream model, and in what way this is going to be broken ? Anyway, I expect to be corrected by some of the opm developers, but I don't think vanilla puppet modules in rdo is realistic goal. Only 22 modules out of 59 present in OPM package are from upstream openstack. The rest is scattered around the galaxy. Fixing upstream CI in openstack may not be enough. On Thu, 2016-02-04 at 16:49 +0100, Emilien Macchi wrote: branches, branches. so? Other reasons to have a plan B when "no downstream patches" is not an applicable policy. Fabien, can we begin to transfer gitnetics jobs to SF ? I'd like to know what happens when the two meet.