On Tue, Mar 13, 2018 at 8:43 AM, Barak Korren <bkor...@redhat.com> wrote:
>
> On 12 March 2018 at 16:44, Sandro Bonazzola <sbona...@redhat.com> wrote:
>>
>>
>>
>>
>>
>> 2018-03-12 15:36 GMT+01:00 Eyal Edri <ee...@redhat.com>:
>>>
>>>
>>>
>>> On Mon, Mar 12, 2018 at 3:11 PM, Yedidyah Bar David <d...@redhat.com>
>>> wrote:
>>>>
>>>> On Mon, Mar 12, 2018 at 12:50 PM, Nir Soffer <nsof...@redhat.com> wrote:
>>>> > On Thu, Mar 8, 2018 at 4:00 PM Sandro Bonazzola <sbona...@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/#the-automationyaml-file
>
> --
> 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
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to