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

Tue Nov 22 08:25:26 UTC 2016

+1

On Tue, Nov 22, 2016 at 9:18 AM, Vinzenz Feenstra <vfeenstr at redhat.com> wrote:
>
> 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/rust-lang/rust/
> https://github.com/kubernetes/kubernetes
>
>
> I would add also https://github.com/ManageIQ/ which we as oVirt devels are
> contributing to regularly.
>
>
> https://github.com/cockpit-project/cockpit
> 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
>
> _______________________________________________
> 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