GSoC idea to setup Gitlab for Fedora Hosted, looking for mentors

[Toshio Kuratomi]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120310/bde640db/attachment.sig>