On Fri, Mar 09, 2012 at 02:31:45PM -0500, Dan Allen wrote:
On Thu, Mar 8, 2012 at 22:43, ranjib dey <dey.ranjib(a)gmail.com>
wrote:
I maintain the gitlabhq instance for our infrastructure, I'll be happy to
take it up if you guys are ok. Setting up gitlabhq is pretty easy, we
might have some plumbing work for importing the existing public keys/
repos. Gitlabhq uses gitolite under the hood for repository management, so
from a packaging standpoint its only the rails stack that we'll need to
package and gitolite can have its own rpm.
Ranjib, that would be great! Would you be willing to play the role of mentor?
It sounds like it would be a good role since you have the right expertise to
provide guidance, and that way you would only need to check in on the progress.
If so, feel free to add yourself on the
page: https://fedoraproject.org/wiki/
Summer_coding_ideas_for_2012#
Setup_Gitlab_as_a_front_end_for_Fedora_Hosted_git_repositories
Btw, I talked to a few people who know the GSoC program and they agreed that a
proof-of-concept is sufficient for a project to be considered complete. If you
go further and get it all running on a production instance w/ full cooperation
from the infra & engineering teams, then bonus!
So I would somewhat disagree with this. But it really has to do with the
goals that we're attempting to achieve. I assume that the goal is to move
fedorahosted (at least the git repositories) onto a Fedora hosted gitlabhq
instance.
To do that, we need the following from a Fedora Infrastructure POV:
* A team of maintainers that are familiar with deploying the code and
committed to doing work as part of the fedora admin team. They ideally
come from a group that depends on the work that's being done so that they
have a vested interest in making it happen. For instance, see the Fedora
Insight Team and their deployment of drupal.
* gitlabhq and dependent packages packaged and maintained in Fedora and
EPEL 6.
* A working proof of concept which we can puppetize the configs from so that
we know to deploy we just tell puppet to install the appropriate rpms and
then push the configs to the box.
Now, in my experience, the GSoC program is much like a summer job. After
the summer, the student often moves on to other things.
If that's the case using GSoC to produce a proof-of-concept for gitlabhq
isn't going to be really helpful to getting it deployed for fedorahosted *by
itself*. If it's part of a larger effort, it may indeed be useful. You'll
need to build a team of people who are knowledgable about gitlabq and want
to do the long term maintainance tasks mentioned above (maintaining the
needed packages in Fedora; maintaining the site in Fedora Infrastructure).
That team can then identify what tasks a short term contributor can work on
as a GSoC student to help realize the goal.
Just remember, as you're doing this, that the long term support burden is
the harder problem to solve. Make sure that whatever tasks the GSoC student
achieves do not make it so that the long term maintainers have to rewrite the
GSoC student's work before they understand how it all works.
-Toshio