On Mon, 2013-11-11 at 16:48 +0400, Peter Lemenkov wrote: Sounds like a good idea in general, except for I'd advise for avoiding GitHub at all costs after years of experience with said service. It sucks for collaboration greatly: 1.) It has really shitty ACLs 2.) No way to disable force pushes 3.) No way to disable half-hearted attempt at pull request (no way to cherry-pick things, always makes a merge commit even when fast forward is possible) processing is utterly confusing to potential contributors 4.) No support for Git protocol (!?) Apart from that, more on a personal note, they do frequent changes to their already largely bulky and confusing UI making it really hard to keep up with it. For me it's definitely not been a pleasure working with github. Sorry if the message was too negative. Have a nice day! Lubo

+1 to own hardware (I can provide something, but see below) good news, but we're lacking manpower here even for simple tasks once upon a time, during some builder crisis, I've installed a virtual machine to be added to the pool, and asked for howto/offered access to someone who would configure and maintain it ... no one ever gave me clear enough(*) instructions or sent ssh key to get access to do it himself (*) "you have to install and configure plague" doesn't count, my todo list is kilometres long and I don't have enough enthusiasm to put it on top and go figure out myself; neither I can commit to supporting something 24/7, I like to go hiking, sailing, I have a family to care of ... K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol(a)jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."

2013/11/11 Miro Hrončok <mhroncok(a)redhat.com&gt; Hi Miro, The problem is to get everything properly tested. Specially I'm reproducing my own koji instance (currently used for arm port), but it's not using pkgdb/bodhi yet and the koji policy isn't there. Right now I'm working on testing git/koji/ansible bridging. That been said, from the packager perspective. I want to rely emphasis that the bottle neck isn't in the infra side. There are still lot of pending packages hanging for review and that's really make me sick not to have them in. Also despite the plague infra isn't certainly outdated and I'm working on the move, it's probably more efficient and requires less resources to work than koji does, specially as we don't need to regen-repo each time the external repo have changed. So that's something that can eventually be worked on by someone else: - having a script that detect the external-repo for each build target, store earch repomd.xml timestamp to immediately send a koji regen-repo command for any change. That would avoid the need to mirror the whole upstream fedora repo. Also another task is to right now allow a bridge from cvs2git for the packager work. I know ktdreyer also use that to maintain xbmc, but I haven't seen anything appearing into the rpmfusion-packager package. Also an unknown task is to convert the multilibs x86_64 plague config. I expect mash will handle the repo generation, but I don't know how to specify where to copy the steam.i686 (and others multilibs corner cases) to the x86_64 repository. So it's just a few issues. Probably most could be sorted into the bugzilla, so anyone can pick simple task that do not need special access. Here is the tracker bug I've just set: https://bugzilla.rpmfusion.org/show_bug.cgi?id=3023 Nicolas (kwizart)