On 13 March 2018 at 09:02, Yedidyah Bar David <[email protected]> wrote: > On Tue, Mar 13, 2018 at 8:43 AM, Barak Korren <[email protected]> wrote: >> >> On 12 March 2018 at 16:44, Sandro Bonazzola <[email protected]> wrote: >>> >>> >>> >>> >>> >>> 2018-03-12 15:36 GMT+01:00 Eyal Edri <[email protected]>: >>>> >>>> >>>> >>>> On Mon, Mar 12, 2018 at 3:11 PM, Yedidyah Bar David <[email protected]> >>>> wrote: >>>>> >>>>> On Mon, Mar 12, 2018 at 12:50 PM, Nir Soffer <[email protected]> wrote: >>>>> > On Thu, Mar 8, 2018 at 4:00 PM Sandro Bonazzola <[email protected]> >>>>> > wrote: >>>>> >> >>>>> >> Following today call, I'm going to push a patch for dropping all >>>>> >> rawhide >>>>> >> jobs from jenkins. >>>>> >> This should help avoiding distractions and reducing patches blocked >>>>> >> by >>>>> >> rawhide issues. >>>>> > >>>>> > >>>>> > Hi Sandro, >>>>> > >>>>> > I worked hard to get ioprocess and ovirt-imageio working on fcraw, so >>>>> > this >>>>> > change will create extra work for me to fix the regressions later when >>>>> > we >>>>> > enable fcraw again. >>>>> > >>>>> > Please revert the change for the ovirt-imageio and ioprocess projects. >>>>> >>>>> I'd like too to keep fcraw, for otopi, now pushed >>>>> https://gerrit.ovirt.org/88816 . >>>>> >>>>> Perhaps for the time being it's best if other projects' maintainers do >>>>> the same, if they want to, and commit to fixing issues in fcraw quickly >>>>> (I hope I do...). >>>> >>>> >>>> Maybe its a good oppertunity to move the projects to V2, so the settings >>>> will be done inside the project itself and not in Jenkisn repo. >>>> Also, maintainers needs to understand that if fcraw build is failing no >>>> other distro will be deployed to tested ( as communicated numerous times >>>> already ), so if you're not sure fcraw will work >>>> keep it on check-patch only and don't add build-artifacts jobs. >>> >>> >>> Can you point to the documentation for V2? >> >> >> The 1st one is on-the-house ;) Want us to send patches to move otopi to v2? > > You know, patches are always welcome :-)) > > But I can't promise I'll have too much time to work with you on this. > Before continuing, and even reading the docs: Is it possible to remain in > V1 for some branches (say, 4.2) and move to V2 for others (master)?
Its possible, as well as having both work side-by-side (and run the same tests/builds twice on every patch). But this will make for a confusing UX... > > Also, if you ask me, now might be a good time to change our naming. > While we call our "Build and test standards", _Standards_, I am not aware > of any other project or CI system that uses them. We're trying to change that. > 'automation/' was not > a good name, as it had high chances to collide with other stuff. Same is > for 'automation.yaml'. Perhaps rename at least latter to 'oVirt-CI-conf.yaml' > or something like this? Over time, projects will move to V2 and eventually > get rid of 'automation/'. V2 supports several other names for the yaml file, the directory name can be customized as well. > > Alternatively, find if there are any accepted real standards for these things, > and consider adopting them. I am not aware of any, personally, didn't search. There are none, everything we`ve found there is a de-facto standard that is hard-wired to a very specific set of implementation concepts and technologies (e.g. .travis.yaml and Jenkinsfile) to my knowledge we`re the only ones that tried to define things in such a way that enables different implementations. > >> >> Docs are being worked on but in essence V2 makes the UX for gerrit projects >> similar to the way things have worked for GitHub projects for a while now >> [1]. >> >> V2 does provide way more then what is documented there (you need more to be >> able to cover complex scenarios like supporting specific sets of >> architectures in specific distributions), but what we have there is enough >> to get the basic ideas and do initial work. >> >> [1]: >> http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHub/#the-automationyaml-file >> >> -- >> Barak Korren >> RHV DevOps team , RHCE, RHCi >> Red Hat EMEA >> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > Didi -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
