
On Tue, Mar 13, 2018 at 8:43 AM, Barak Korren <bkorren@redhat.com> wrote:
On 12 March 2018 at 16:44, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
2018-03-12 15:36 GMT+01:00 Eyal Edri <eedri@redhat.com>:
On Mon, Mar 12, 2018 at 3:11 PM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Mar 12, 2018 at 12:50 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Mar 8, 2018 at 4:00 PM Sandro Bonazzola <sbonazzo@redhat.com> 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/...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi