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)? 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. '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/'. 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. > > 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
