----- Original Message -----
From: "Eyal Edri" <eedri(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Barak Korren" <bkorren(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "board" <board(a)ovirt.org>, "Michal
Skrivanek"
<mskrivan(a)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(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Barak Korren" <bkorren(a)redhat.com>
> > To: "Brian Proffitt" <bproffit(a)redhat.com>
> > Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, board(a)ovirt.org,
"devel" <
> devel(a)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
> > 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
> > 2. Have tests and builds running on oVirt's CI system.
> > 3. Have artefacts served from oVirt's mirrors.
> > 4. Have bugs tracked in oVirt's bugzilla.
>
> 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 )
> 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.
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.
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.
>
> >
> > On 21 November 2016 at 19:07, Brian Proffitt <bproffit(a)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(a)ovirt.org
> > >
http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > --
> > Barak Korren
> > bkorren(a)redhat.com
> > RHEV-CI Team
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> >
http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)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)