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

[Eliran Mesika]

Eliran from GitLab here - I lead our strategic partnerships. I read the valid 
concern raised by Alex and we actually have a public policy on this which you 
can read on: https://about.gitlab.com/about/#stewardship. We will always 
welcome any feature request raised by the Debian community and will be happy to 
discuss adding it to the community edition of GitLab on a case-by-case basis. 
We already have a positive track record in similar cases as we’ve had a request 
to make our branded login page a community feature by the VLC community, which 
we happily agreed with and made publicly available.

I would want to emphasize that we’re here to help and will consider any 
requests made by the community so you won’t need to maintain/fork/patch 
anything on GitLab. More over, you can always see our direction for 
Community/Enterprise features going forward on our direction page: 
https://about.gitlab.com/direction/ 

Eliran

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

[Eliran Mesika]

Hi Alex,
As I wrote earlier, we're open to making certain features available upon
request. In the specific case of the feature that was discussed - could you
please elaborate what is missing and what functionality is available on the
Enterprise edition that you'd like to be made public? We want to better
understand the use-case and the requirements to respond to this request.

Thanks,
Eliran

On Wed, Jun 22, 2016 at 9:53 AM Alexander Wirt  wrote:

> On Wed, 22 Jun 2016, Pirate Praveen wrote:
>
> > [adding gitlab folks in cc]
> >
> > On Saturday 11 June 2016 02:16 PM, Alexander Wirt wrote:
> > > On Sat, 11 Jun 2016, Ole Streicher wrote:
> > >
> > >> Pirate Praveen  writes:
> >  Debian needs feature X but it is already in the e.nterprise
> version. We make
> >  a patch and for commercial reasons it never gets merged (they
> already sell it
> >  in the enterprise version). Which means we will have to fork the
> software and
> >  keep those patches forever. Been there done that. For me, that isn't
> >  acceptable.
> >  I don't want another Nagios.
> > >>>
> > >>> I agree this is a legitimate concern. I have asked Gitlab Inc for
> their
> > >>> policy on merge requests to Gitlab CE for features already in Gitlab
> EE.
> > >>> Based on their reply, we can decide how to proceed. If their reply is
> > >>> positive, I will ask them to make it public, and we can go ahead
> with a
> > >>> debian.net instance of Gitlab. If their reply is negative, we can
> drop
> > >>> gitlab and consider Pagure (second best option).
> > >>
> > >> We do patching as part of our daily packaging already: to replace (or
> > >> circumvent) non-dfsg functionality, to integrate into our environment,
> > >> and everything else that upstream is not willing or able to apply
> > >> himself but is good in our opinion. Depending on the package, you may
> > >> find huge patches for our packages
> > >>
> > >> I would not see why a missing functionality of gitlab would be
> different
> > >> here.
> > > Given my personal expericence with so called opencore software, I do.
> > >
> > > Alex
> > >
> > >
> >
> > Hi Alex,
> >
> > GitLab folks have indicated their interest to consider solving access
> > problems for debian (possibly releasing relevant code as Free Software
> > if we are serious about using gitlab). They would like to have a call
> > with relevant admins (since you being git.debian.org maintainer, your
> > presence would be essential, if we were to do such a call). Would you be
> > open to such a call?
> I really prefer async communication like mail.
>
> Alex
>
> --

Best,
Eliran