[ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

Mon Nov 21 19:52:50 UTC 2016

> On 21 Nov 2016, at 19:48, Vojtech Szocs <vszocs at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Eyal Edri" <eedri at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "Barak Korren" <bkorren at redhat.com>, "devel" <devel at ovirt.org>, "board" <board at ovirt.org>, "Michal Skrivanek"
>> <mskrivan at redhat.com>
>> Sent: Monday, November 21, 2016 7:23:44 PM
>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>> 
>>> On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs <vszocs at redhat.com> wrote:
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Barak Korren" <bkorren at redhat.com>
>>>> To: "Brian Proffitt" <bproffit at redhat.com>
>>>> Cc: "Michal Skrivanek" <mskrivan at redhat.com>, board at ovirt.org, "devel" <
>>> devel at ovirt.org>
>>>> Sent: Monday, November 21, 2016 7:01:08 PM
>>>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>>>> 
>>>> -1

I wonder if 8x +1 beats one -1 :)

>>>> Not because of anything with the project itself - I think it is
>>>> genuinely awesome, but because I expect a project that emerges out of
>>>> the incubation process to "look" like an oVirt project, by which I
>>>> mean:
>>>> 1. Have the code in the oVirt Gerrit

I wonder why that would be required. We experimented with other projects being off gerrit as well(e.g. cockpit-ovirt) and bug tracking out of redhat bugzilla and for certain projcts it makes sense. With more integration with other upstream projects I see us moving to github even more...

>>>> 2. Have tests and builds running on oVirt's CI system.

Can we run mobile testing on current infra?

>>>> 3. Have artefacts served from oVirt's mirrors.

What artifacts? The final APK? Why? It's not a yum repo. 

>>>> 4. Have bugs tracked in oVirt's bugzilla.

No
That should never be imposed on any new project. If someone loves slow outdated tools, so be it, but for new projects I again do not see us promoting it in future

>>> 
>>> For 1 and 4, I feel that the benefit of allowing some projects to be hosted
>>> on GitHub (attract & involve community through GitHub's public service)
>>> does
>>> out-weigh the rule of strict consistency (have everything in oVirt Gerrit).
>>> 
>>> 
>> Any project in oVirt gerrit can be mirrored to GitHub, and most of them are
>> ( see github.com/oVirt )

We do mirror it IIRC (or it may have been cockpit-ovirt), it's just the other way around - the master copy is at github

>> 
>> 
>>> Although, not sure how hard would it be to modify oVirt CI system to allow
>>> building GitHub hosted projects.
>>> 
>> 
>> We are supporting it, Lago is an example of such project.
>> 
>> 
>>> 
>>> The guidelines should be clear about whether a project must be hosted via
>>> oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla,
>>> etc.
>>> 
>> 
>> I don't think its a must, but its highly recommended IMO, and will help the
>> project grow.
>> Imagine this scenario:
>> 
>> the project grows and uses its own CI/testing frameworks and reaches a
>> point it wants to join the oVirt eco-system,
>> At that point it will be much harder to integrate it if at all, assuming
>> the tools he's been using were not aligned with
>> the tooling other projects are using.
>> 
>> Also - in terms of release process, its will be very hard to include it in
>> an official oVirt release if he wishes to do so,
>> as all oVirt projects are built in the current infra and shipped as a
>> single repository.

You're missing the point it's not a yum repo.

> 
> Eyal, I agree with your points.
> 
> I just wanted to point out the possibility of hosting project's
> sources on GitHub (point 1 from Barak's list). And as you wrote,
> Lago is a good example of such project.
> 
> Using standard oVirt CI infra & tools (points 2 & 3 from Barak's
> list) should be mandatory for all oVirt projects, to keep things
> manageable from build/release perspective. Full agreement here.
> 
> As for bug tracking (point 4 from Barak's list), I see Lago using
> GitHub's issue tracking interface, so this should be OK too..
> 
> In general, I'd say that moVirt maintainers should clearly voice
> their vision on converging (or not) towards points 1,2,3,4 that
> Barak has mentioned in his email.

I would say no. And that is fine

> 
> For me, having source code & issues on GitHub, but using standard
> oVirt CI infra & tools, is still acceptable for an oVirt project,
> but it's just my own opinion.

I agree we can mix and match, though in this case I'm not sure how realistic is to run CI for an APK

> 
>> 
>> 
>>> 
>>>> 
>>>> On 21 November 2016 at 19:07, Brian Proffitt <bproffit at redhat.com>
>>> wrote:
>>>>> All:
>>>>> 
>>>>> The moVirt Project was initially accepted as an oVirt incubator
>>> project in
>>>>> February 2015. It has been a successful subproject for quite some time
>>> and
>>>>> it is well due for being accepted as a full oVirt project. I believe
>>> it is
>>>>> appropriate to post a Call for Vote on the Devel and Board lists.
>>>>> 
>>>>> http://www.ovirt.org/develop/projects/project-movirt/
>>>>> 
>>>>> A “healthy” project, as determined by the oVirt Board, can be found at
>>>>> http://www.ovirt.org/develop/projects/adding-a-new-project/
>>>>> 
>>>>> Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7
>>> votes
>>>>> should be received to formalize this project as an full oVirt project.
>>>>> Please use the following vote process:
>>>>> 
>>>>> +1
>>>>> Yes, agree, or the action should be performed. On some issues, this
>>> vote
>>>>> must only be given after the voter has tested the action on their own
>>>>> system(s).
>>>>> 
>>>>> ±0
>>>>> Abstain, no opinion, or I am happy to let the other group members
>>> decide
>>>>> this issue. An abstention may have detrimental affects if too many
>>> people
>>>>> abstain.
>>>>> 
>>>>> -1
>>>>> No, I veto this action. All vetos must include an explanation of why
>>> the
>>>>> veto is appropriate. A veto with no explanation is void.
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> Brian Proffitt
>>>>> Principal Community Analyst
>>>>> Open Source and Standards
>>>>> @TheTechScribe
>>>>> 574.383.9BKP
>>>>> 
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Barak Korren
>>>> bkorren at redhat.com
>>>> RHEV-CI Team
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Eyal Edri
>> Associate Manager
>> RHV DevOps
>> EMEA ENG Virtualization R&D
>> Red Hat Israel
>> 
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>> 