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

Vinzenz Feenstra vfeenstr at redhat.com
Tue Nov 22 08:18:17 UTC 2016 

> On Nov 22, 2016, at 9:12 AM, Tomas Jelinek <tjelinek at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Nir Soffer" <nsoffer at redhat.com>
>> To: "Michal Skrivanek" <mskrivan at redhat.com>
>> Cc: "devel" <devel at ovirt.org>, "board" <board at ovirt.org>
>> Sent: Monday, November 21, 2016 10:00:05 PM
>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>> 
>> 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 :-)
> 
> adding my obviously biased +1, so not sure if it counts...
> 
>> 
>> +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/systemd/systemd>
>> https://github.com/rust-lang/rust/ <https://github.com/rust-lang/rust/>
>> https://github.com/kubernetes/kubernetes <https://github.com/kubernetes/kubernetes>
> 
> I would add also https://github.com/ManageIQ/ <https://github.com/ManageIQ/> which we as oVirt devels are contributing to regularly.

https://github.com/cockpit-project/cockpit <https://github.com/cockpit-project/cockpit>
https://github.com/OpenShift <https://github.com/OpenShift>


> 
>> 
>> 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?
> 
> We are using travis for this. Our complete config file is:
> language: android
> script: "./gradlew build"
> android:
>  components:
>    - platforms-tools
>    - tools
>    - build-tools-21.1.2
>    - android-21
> 
> We don't have any additional tooling developed or anything like that.
> If we will start thinking about doing some custom/complicated stuff, we
> may consider moving to ovirt's CI. Currently, I don't see a reason.
> 
>>> 
>>>>>>> 3. Have artefacts served from oVirt's mirrors.
>>> 
>>> What artifacts? The final APK? Why? It's not a yum repo.
> 
> We need to serve them using google play store so it will reach the users easily. 
> We could serve also RPM packaged APKs 
> or even create our alternative "something like play store" but Im not sure what benefits 
> it would bring us.
> 
>>> 
>>>>>>> 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
> 
> +1
> 
> Well, long story short, moVirt is a simple small tool developed by a very small team
> and occasionally contributed by community (mostly as outreachy interns or intern candidates). 
> It needs a swift, stable, minimal and well known tooling around which does exactly what we need.
> The current combination of github for code and issue tracking + travis for simple CI 
> served us fantastically. I'm quite against moving to other place just because it may bring 
> some benefits in the 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
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org <mailto:Devel at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161122/2bc7f9ce/attachment-0001.html>

More information about the Devel mailing list