Hi, Le 02/02/2016 16:09, Gabriele Cerami a écrit : > Hi, > > first of all, I don't know how to sobscribe to this ml, or if it's the > right place to post this discussion.
You can use mailman UI here, softwarefactory-dev is a public ML. https://www.redhat.com/mailman/listinfo/softwarefactory-dev > I wanted to share some ideas on how to integrate the tool called > ginetics, that is automating the maintenance of the midstream OPM repos. > > Briefly, this tool detects new merges on upstream projects, downloads > and tests them before merging into the local repo. For repos that > maintain mainly a rhos7-patches branch with the backports, it > automatically tests the cherry-picking and then proposes reviews in > gerrit when the cherry-pick passes tests. It's semi interactive, it's > capable of responding to commands that can be inserted as comments to > the review. > I see that you intention is to use delorean for rdo for all the master > branches in the projects. Delorean works at package level, not at repo > level. If you don't care to maintain a secondary repo with local > patches, delorean is the right thing to use. But if in any way you need > a local repository to store local changes, gitnetics may be useful to > identify problem even before creating the package. 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. > For what I understand of software factory, it works well as primary > pipeline for a set of projects, but if we are chasing another upstream > project, with its own repositories, it may need some manual import to > use the sf pipeline. 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: python-sfrdo has created two repositories: - nova - nova-distgit The first one is like a mirror repository. http://rpmfactory.beta.rdoproject.org/r/gitweb?p=nova.git;a=summary master and stable/liberty has been imported and those branches as well as tags are synchronized from upstream every night by a periodic job http://rpmfactory.beta.rdoproject.org/jenkins/job/upstream-update/654/consoleFull We can easily I think configure which branches we want to sync, for now this is just the default. This nova repository also include a liberty-patches branch where gerrit reviewes are attached to store additional patches. The second repository is just where the packaging lands: http://rpmfactory.beta.rdoproject.org/r/gitweb?p=nova-distgit.git;a=summary There is the rpm-master branch (for delorean) and a rdo-liberty branch for the liberty packaging definition. > I think the best approach may be to add another tab to the dashboard, > called "upstream" where one can add and set up how to watch an existing > upstream project. So for example, in the upstream tab, one can add a > watch for the stable/kilo branch in puppet-nova, thus configuring a tool > like gitnetics that will replicate upstream changes into sf > repositories. 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. 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. > I don't want to add more or goo deeper than this, I'd like to know > first if I understand correctly how sf is working and if what I propose > may seem acceptable. Alright, sure we need to adjust our understanding of each tools to integrate them correctly. Best regards, Fabien > Thanks. > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev > _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
