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

> On 21 Nov 2016, at 19:48, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote: > > > > ----- Original Message ----- >> From: "Eyal Edri" <eedri(a)redhat.com&gt; >> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >> Cc: "Barak Korren" <bkorren(a)redhat.com&gt;, "devel" <devel(a)ovirt.org&gt;, "board" <board(a)ovirt.org&gt;, "Michal Skrivanek" >> <mskrivan(a)redhat.com&gt; >> 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(a)redhat.com&gt; wrote: >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Barak Korren" <bkorren(a)redhat.com&gt; >>>> To: "Brian Proffitt" <bproffit(a)redhat.com&gt; >>>> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com&gt;, board(a)ovirt.org, "devel" < >>> devel(a)ovirt.org&gt; >>>> 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(a)redhat.com&gt; >>> 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(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>>> >>>> >>>> -- >>>> Barak Korren >>>> bkorren(a)redhat.com >>>> RHEV-CI Team >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/devel >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel