> On Nov 22, 2016, at 9:12 AM, Tomas Jelinek <[email protected]> wrote: > > > > ----- Original Message ----- >> From: "Nir Soffer" <[email protected]> >> To: "Michal Skrivanek" <[email protected]> >> Cc: "devel" <[email protected]>, "board" <[email protected]> >> 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 <[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 :) >> >> 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 <[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) >>>>> >>> _______________________________________________ >>> Devel mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/devel >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel >> <http://lists.ovirt.org/mailman/listinfo/devel> > _______________________________________________ > Devel mailing list > [email protected] <mailto:[email protected]> > http://lists.ovirt.org/mailman/listinfo/devel > <http://lists.ovirt.org/mailman/listinfo/devel>
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
