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

Eyal Edri eedri at redhat.com
Mon Nov 21 20:08:50 UTC 2016 

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



-- 
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161121/2c2affab/attachment-0001.html>

More information about the Devel mailing list