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

Tomas Jelinek tjelinek at redhat.com
Tue Nov 22 08:12:16 UTC 2016 


----- 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.

> 
> 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

More information about the Devel mailing list