> On 21 Nov 2016, at 21:09, Eyal Edri <[email protected]> wrote: > > > >> On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek <[email protected]> >> wrote: >> >> >> > On 21 Nov 2016, at 19:48, Vojtech Szocs <[email protected]> wrote: >> > >> > >> > >> > ----- Original Message ----- >> >> From: "Eyal Edri" <[email protected]> >> >> To: "Vojtech Szocs" <[email protected]> >> >> Cc: "Barak Korren" <[email protected]>, "devel" <[email protected]>, >> >> "board" <[email protected]>, "Michal Skrivanek" >> >> <[email protected]> >> >> 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 <[email protected]> wrote: >> >>> >> >>> >> >>> >> >>> ----- Original Message ----- >> >>>> From: "Barak Korren" <[email protected]> >> >>>> To: "Brian Proffitt" <[email protected]> >> >>>> Cc: "Michal Skrivanek" <[email protected]>, [email protected], "devel" < >> >>> [email protected]> >> >>>> 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? > > We won't know until we'll try right? fact is no one asked for it until now..
True. Though...I do appreciate the offer to look into it(I hope I didn't misunderstand:), but honestly there are more urgent things to resolve with lago stability...that is way more important at the moment IMHO > >> >> >>>> 3. Have artefacts served from oVirt's mirrors. >> >> What artifacts? The final APK? Why? It's not a yum repo. > > The fact we're only hosting RPMs (not entirely right, we host images as well) > doesn't mean we can't host anything else, we're actually working on support > for building/deploying containers. > I'm sure we can find a way if the project owner wants it. It is surely doable, but it doesn't give us much. The availability as a github release is good enough for development, and the "official" package is delivered through google play anyway > >> >> >>>> 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 > > I agree this point is less relevant, and each project can handle his own > tracking ( but again, if he will want to be released as part of oVirt and not > independently, then I'm not sure he'll have a choice but to align ) I'm not sure, I do think we will want to move off for more and more parts of ovirt. How to keep a unified approach is to be seen indeed, we certainly don't want to diverse too much.... > >> >> >>> >> >>> 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. > > See my comments above on supporting other artifacts than rpms. > > I think you're missing the point of the advantages such a project can get by > joining, instead of managing its infra himself ( if it has any ), > It gets a massive CI/CD infrastructure already built and working, and will be > able to do integration / testing with a real oVirt instance (using OST for > e.g). I do not see a problem to do that once we get that far. I really don't, but currently it's premature. We do not have a support, we do not have such tests... Thanks, michal > >> >> > >> > 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 > > I'm pretty sure that if we wanted to check that option, it will be possible > even if by using emulators, but no one from the project has ever approached > us so I can't really say anything before I see requirements. > I tend not to rule out anything I haven't verified possible before. > > >> > >> >> >> >> >> >>> >> >>>> >> >>>> On 21 November 2016 at 19:07, Brian Proffitt <[email protected]> >> >>> 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 >> >>>>> [email protected] >> >>>>> http://lists.ovirt.org/mailman/listinfo/devel >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Barak Korren >> >>>> [email protected] >> >>>> RHEV-CI Team >> >>>> _______________________________________________ >> >>>> Devel mailing list >> >>>> [email protected] >> >>>> http://lists.ovirt.org/mailman/listinfo/devel >> >>> _______________________________________________ >> >>> Devel mailing list >> >>> [email protected] >> >>> 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) >> >> > > > > -- > 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 [email protected] http://lists.ovirt.org/mailman/listinfo/devel
