[Spice-devel] gitlab

[Daniel P. Berrange]

On Fri, Sep 30, 2016 at 05:13:44PM +0200, Fabiano Fidêncio wrote:
> On Fri, Sep 30, 2016 at 1:48 PM, Victor Toso <lists at victortoso.com> wrote:
> > Hi again!
> >
> > On Wed, Jun 22, 2016 at 04:48:39PM +0200, Victor Toso wrote:
> >> Hi all,
> >>
> >> I created a spice group in gitlab [0] mirroring the repository from
> >> freedesktop which should be updated every hour.
> >>
> >> [0] https://gitlab.com/groups/spice
> >
> > https://gitlab.com/spice works too.
> >
> >>
> >> But I would like to discuss the transition to use gitlab for source
> >> code at some time soon. One of the main reasons is the management for
> >> users and repos being much easier with no need to file a bug and wait
> >> some fdo admin to have time to do it.
> >>
> >> As pointed by Daniel [1] while discussing the migration of libosinfo
> >> to gitlab, we would still be under open source infrastructure with
> >> good self-service API for managing the project plus other benefits.
> >>
> >> [1] https://www.redhat.com/archives/libosinfo/2016-March/msg00000.html
> >>
> >> The idea is keeping freedesktop and github [2] as a mirror of gitlab
> >> repos. I'm not sure about moving from bugzilla to the issues thing but
> >> I guess it might make sense in the future.
> >>
> >> [2] https://github.com/SPICE
> >>
> >> The pull requests can be disable int gitlab (while we can't on github)
> >> but I wonder if should do that?
> >>
> >> As we are at it, I would suggest to rename:
> >>
> >> * linux/vd_agent to spice-vdagent (currently vdagent on gitlab)
> >> * win32/vd_agent to spice-vdagent-win (currently vdagent-win on gitlab)
> >
> > * Marc-André did not agree with renaming ^
> >
> >>
> >> It would be great to hear from current contributors about this!
> >>
> >> Cheers,
> >
> > So, I put this on hold for some time but it would be great to discuss
> > this once more.
> >
> > Last week I started to play with continuous integration in gitlab [0]
> > which can be very useful to track if given commit is breaking
> > builds, tests, etc. We also plan to setup a copr [1] repo to provide
> > fedora builds to latest upstream. Pavel has worked in a script [2] that
> > does that (if commit passes in previous stages like building, tests).
> >
> > [0] https://about.gitlab.com/gitlab-ci/
> > [1] https://copr.fedorainfracloud.org/
> > [2] https://gitlab.com/xerus/ci/tree/master
> 
> I guess is worth to check the CentOS CI. It can be easily integrated
> with github/gitlab.
> virt-viewer already makes use of that, libvirt as well as far as I remember.

I'd be happy to add spice bits to the libvirt project on CentOS CI. It would
have some advantages, in that it lets us chain-build. eg we can build
virt-viewer against the just-built spice-gtk.

SPICE is auto-conf based, so it'd be easy enough for us to handle - we
just need to add a project definition to our CI config:

  https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=tree;f=projects;hb=HEAD

This is all tangential to where you host GIT - the CentOS CI system doesn't
care where the GIT repos are located.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|