Re: GitLab packaging progress and discussion about deployment on fedorahosted
On Wed, 03 Jul 2013 21:57:23 +0300
Axilleas Pipinellis <axilleaspi(a)ymail.com> 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
Attachments:
- signature.asc (application/pgp-signature — 836 bytes)