On 03 Feb, Fabien Boucher wrote: > > So to summarize Gitnetic will help for such cases: > - we have a *-patches branch with some "not yet/never" included upstream > changes > and where we want to cherry-pick upstream changes into it. > - we want to cherry-pick upstream changes into a "mirror" repository where we > already > have included "not yet/never" included upstream changes. > > Gitnetic is then able to take actions when the cherry-pick is not possible, > like > warning the maintainer via a notification like a Gerrit review, ... > > Let me know if I miss understood.
Yes, gitnetics will try the cherry-pick and launch unit tests on the merged result. If the cherry pick is not possible, it will ask for human interaction in the form of comments on a gerrit review. It would also be able to include upstream changes into mirror repository on non -patches branches. This is not necessary for most of the upstream projects, because the master branches are tested by delorean, but delorean is not testing any local patch. It's the goal of rdo, offering packages from unpatched repositories, but it's not clear yet if for some opm repositories for example, we will be able to ship unpatched upstream releases. > Actually we have already imported all projects from rdoinfo (rdo.yml) into > RPM factory. > This has been done by a tool called python-sfrdo. Let's take > an example: Nova: Yes, sorry, with "manual import" I meant that the mirror repository is maintained manually, I did not know about the periodic job. But then again nothing is testing local patches with new upstream changes, when the mirror is synchronized. We are yet not sure how much we want to test these upstream changes. Gitnetics tests even before merging... > We haven't yet thought to tightly integrate such options in the dashboard. > We first try to implement RPM Factory features in a separate tool > called python-sfrdo and evaluate after if there are generic enough to backport > them in Software Factory. Gitnetics is written in python too, and it uses yaml configuration file to handle all the various options for the projects it has to replicate. > But yes I think we can find a way to let a PTL/CORE member of a packaging > project to select the mechanism that will handle the sync of the "mirror" > repo: > > Classical: like we have today in RPM Factory: Naive sync of master and > stable/* > periodically. > Gitnetic: Classical is deactivated and Gitnetic managed the sync of branches > from upstream in a smarter manner taking in account "not yet/never" included > upstream changes > has been inserted in the branches. Yes, something like this, maybe with more options (gitnetics configuration file contains branch mappings e.g. stable/kilo upstream is replicated in rhos7 downstream) _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
