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

Michal Skrivanek mskrivan at redhat.com
Mon Nov 21 20:56:06 UTC 2016 


> On 21 Nov 2016, at 21:09, Eyal Edri <eedri at redhat.com> wrote:
> 
> 
> 
>> 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..

True. Though...I do appreciate the offer to look into it(I hope I didn't misunderstand:), but honestly there are more urgent things to resolve with lago stability...that is way more important at the moment IMHO

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

It is surely doable, but it doesn't give us much. The availability as a github release is good enough for development, and the "official" package is delivered through google play anyway

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

I'm not sure, I do think we will want to move off for more and more parts of ovirt. How to keep a unified approach is to be seen indeed, we certainly don't want to diverse too much....

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

I do not see a problem to do that once we get that far.  I really don't, but currently it's premature. We do not have a support, we do not have such tests...

Thanks,
michal

>  
>> 
>> >
>> > 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/ff11a5c7/attachment.html>

More information about the Devel mailing list