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