On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek <mskri...@redhat.com> wrote:
> > > > On 21 Nov 2016, at 19:48, Vojtech Szocs <vsz...@redhat.com> wrote: > > > > > > > > ----- Original Message ----- > >> From: "Eyal Edri" <ee...@redhat.com> > >> To: "Vojtech Szocs" <vsz...@redhat.com> > >> Cc: "Barak Korren" <bkor...@redhat.com>, "devel" <de...@ovirt.org>, > "board" <board@ovirt.org>, "Michal Skrivanek" > >> <mskri...@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 <vsz...@redhat.com> > wrote: > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Barak Korren" <bkor...@redhat.com> > >>>> To: "Brian Proffitt" <bprof...@redhat.com> > >>>> Cc: "Michal Skrivanek" <mskri...@redhat.com>, board@ovirt.org, > "devel" < > >>> de...@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? > We won't know until we'll try right? fact is no one asked for it until now.. > > >>>> 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. > > >>>> 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 ) > > >>> > >>> 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). > > > > > 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 <bprof...@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 > >>>>> de...@ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/devel > >>>> > >>>> > >>>> > >>>> -- > >>>> Barak Korren > >>>> bkor...@redhat.com > >>>> RHEV-CI Team > >>>> _______________________________________________ > >>>> Devel mailing list > >>>> de...@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/devel > >>> _______________________________________________ > >>> Devel mailing list > >>> de...@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) > >> > -- 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)
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board