On Wed, 03 Jul 2013 21:57:23 +0300 Axilleas Pipinellis <axilleaspi@xxxxxxxxx> wrote: > Dear infra team and others that this mail may concern, > > As many of you know (I hope :p), one of this year's GSoC projects, is > to package GitLab and all its dependencies for Fedora and later for > EPEL. There have been at least 3 discussion threads about this since > March [0][1][2][3]. Yep. ;) > I have been in contact with GitLab's core team and we talked about how > we could all work together to make this happen and how GitLab could be > eventually deployed in fedorahosted as an alternative git service. For > the time being there are 2 major show-stoppers: So, perhaps this was berried in one of the previous discussions, but I don't think we want to replace fedorahosted. Lets stop saying that. Any gitlab deployment I would like to see as a new service for those that would like that, folks who don't want to be bothered could just keep using fedorahosted. So, moving forward, can we just drop any mention of fedorahosted from this discussion? Call it 'gitlab deployment' or 'gitlab instance for fedora' or something. ;) Please? > 1) GitLab uses some forked gems. ...snip... > I think GitLab's forks don't abide by FESCo's verdict, as both > original and forked gem are called with the same library, eg. require > 'grit', so there is no distinction between them. Right. While these are forked, upstream hasn't fully forked them, they simply bundle them and make local changes. It's up to you or upstream to see if you can unbundle them. That might include some combo of: a) Just getting changes merged with the orig project so no bundling is needed anymore. b) Getting upstream to finish the forking process and rename them/create releases, etc. You can then package them up. c) Adjust gitlab to not need the changed bits, or do things in a different way. > I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about > what changes could be made in order for the forks to get accepted. Great! > > 2) The feature of public browserability for non logged in users is not > yet implemented. > > This long awaited feature is the major show-stopper for getting GitLab > deployed on fedorahosted. Quoting Sytse's proposal: > > > Of the two improvements I think that 2) is the most necessary. > > Without a public project UI Fedora will not switch to GitLab. There > > is already a public project git clone functionality in GitLab. > > Opening up more of the project such as issues might load to > > in-advert exposure of issues. Therefore we want to do it only on a > > major version upgrade. We started with GitLab 6.0 a week ago and > > would like to merge this fast so it can be included in the beta > > released on July 22. If Axilleas works on this then Dmitriy is > > prepared to coach him, this will be needed since this feature will > > impact the whole application. So, would this be trying to merge functionality upstream? Or carry our own patches to handle anon stuff? > > Our proposal would be to: > > A) Start working on the public UI immediately > > B arrange a online meeting between Fedora and GitLab.com people to > > talk about packaging > > C) have beta version of GitLab run on a demo server with Fedora > > project on August 1 We could possibly do a demo in a cloud instance depending on whats involved. > > D) aim to have GitLab in production for all Fedora projects on > > September 1 This is...not likely. :) a) We should not try and move all projects to it. Only folks who want to use it/opt in. b) We have a process for bringing up a new supported service: https://fedoraproject.org/wiki/Request_For_Resources?rd=Infrastructure/RFR I'm sorry it's a bit involved and has many steps. This is to make sure we can actually support something moving forward and don't just get it dumped on us. c) We freeze around release milestones. It's likely that Fedora 20 will be landing sometime in Aug or early Sept, so we would have to make sure not to disrupt our primary mission of producing Fedora. Hope that helps. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
