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@xxxxxxxxx> 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
Attachment:
pgpVGm4_YZVQJ.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
