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@xxxxxxxxxxxxxx> 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/ :| _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel