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

Nir Soffer nsoffer at redhat.com
Mon Nov 21 21:00:05 UTC 2016 

On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek <mskrivan at redhat.com> wrote:
>
>
>> 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 :)

9X :-)

+1 for including the project as is.

If someone wants to run the project test or build it, the right way
to vote is by sending patches and making it happen.

I think we should get out of our gerrit silo and move all ovirt
projects to github. This will give ovirt much better visibility.

Here are some projects developed on github:
https://github.com/systemd/systemd
https://github.com/rust-lang/rust/
https://github.com/kubernetes/kubernetes

Nir

>
>>>>> 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)
>>>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

More information about the Devel mailing list