[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)



On Tue, Jun 07, 2016 at 05:16:09PM +0200, Alexander Wirt wrote:
> On Tue, 07 Jun 2016, Pirate Praveen wrote:
> 
> > On Tuesday 07 June 2016 10:31 AM, Luca Filipozzi wrote:
> > > On Tue, Jun 07, 2016 at 10:19:48AM +0530, Pirate Praveen wrote:
> > >> On 2016, ജൂൺ 6 10:37:25 PM IST, Tollef Fog Heen <tfheen@err.no> wrote:
> > >>> Another prerequisite for d.o hosting is that it runs on a DSA-managed
> > >>> machine.
> > >>
> > >> How do I get such a machine? Since Gitlab Inc, is sponsoring this hosting,
> > >> should we get a new machine and set it up as per DSA standards?
> > > 
> > > I think you start by avoiding us having multiple different git-based services.
> > > 
> > > I don't care which one (gitolite, gitlab) but DSA would prefer if there were
> > > only one to take care of.
> > > 
> > 
> > ok. So I start this process by proposing to move to gitlab for
> > git.debian.org (Is there another process I should follow?). If someone
> > proposes an alternative (gitolite or something else), we will compare
> > the proposed options and decide.
> Ok, I should step in here. For some time I am in the process of setting up an
> alioth replacement for git.d.o. 
> 
> I know that the process is far away from the point where it should be know.
> However the plan is still to move to gitolite. 
> 
> I don't think that gitlab is able to replace git.debian.org in its current
> implementation. Given that gitlab is a monster given its huge number of
> dependencies is another point. I would really prefer to have something more
> simple than gitlab. 
> 
> Alex - with his alioth admin hat on
> 
> P.S. I am on vaction currently, so please don't expect fast answers

Fair enough. One cannot plan to replace a service that is maintained by
someone else, specially when that someone still has plans to maintain it
_and_ disagrees with the replacement.

Also, DSA's wish to keep the number of services down to the minimum
necessary and avoid redundancy is completely reasonable.

It seems to me that the above points means that a gitlab instance would
necessarily have to start outside of the official infrastructure.

OTOH, in my opinion the status of alioth today is hurting the project. I
have been mentoring Google Summer of Code students for 3 years already,
and in the first 2 years every single one of them had problems to do
simple things as settinup git access on alioth. This year both students
were already working on github, me and Tassia (my co-mentor) just asked
them to move to gitlab.com to have the project in a free software
infrastrucure, and I am happy I didn't have to deal again with the mess
that is helping a Debian newcomer start using alioth.

Note that I appreciate the work of the people who maintain alioth very
much, specially Alexander who has been very helpful on IRC. But I don't
really see alioth as having a future.

Yes, gitlab is a monster in terms of dependencies, but it also pretty
much replaces pretty much every useful feature that fusionforge has, and
adds very useful things (such merge requests with code review support,
integrated CI, generation of static pages etc), all that without a
single user having a real shell account on the server. What some call
bloat, others call features.

I think the experiment is valid.

Praveen, I think you could call this new thing something like
labs.debian.net. pkgs.debian.net (the fedora git server is called
pkgs.fedoraproject.org), of even dev.debian.net. or anything else,
really, as long as it exists, and is not called "gitlab" (I agree that
not calling a service by the name of the tool that provides it is a good
thing).

-- 
Antonio Terceiro <terceiro@debian.org>

Attachment: signature.asc
Description: PGP signature


Reply to: