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

gitlab package (was Re: Opt out style recommends)



hi,

On 04/08/2016 05:33 AM, Pirate Praveen wrote:
> See #819854 for a background.
> 
> Currently gitlab recommends letsencrypt, it means someone has to opt in for letsencrypt by running something like
> 
> apt-get install gitlab letsencrypt
> 
> But I would like letsencrypt to be available by default (postinst asks if they want t

while i really appreciate all the work you are doing for the gitlab
package, i honestly have the feeling that you are trying to make too
many decisions on behalf of the system administrator who wants to
install gitlab.

i really don't see any compelling reason why a package like gitlab
should force me to use any special means to encrypt my connection.
there are a number of reasons to use the Debian gitlab packages over the
ones provided by upstream (e.g. omnibus), and one of them is being able
to chose the components i would like to have on my system (or not).

but the way the package is heading seems to take away choices rather
than give me additional ones: e.g. using upstream's gitlab-ce omnibus
packages i am *free* to choose whatever method i like to setup an
encrypted webserver (allowing me to e.g. setup a gitlab instance that is
not accessible from the public internet - something that is impossible
with letsencrypt afaict).

i would love if the gitlab package in Debian was as *minimal* as
possible giving *me* (the admin) the freedom to choose the largest
possible set of components - probably (and likely) at the expense that I
(the admin) will need to setup quite a lot of things myself.

i guess there are *many* things to setup and this might make it
impossible for newbee administrators to setup their own gitlab instance.
but i think that there are ways to accomodate both the seasoned admin
(probably in a corporate environment dictating whatever policies) and
the any random developer (who want an instance for their personal use
without worrying too much about administration).

e.g. instead of making the 'gitlab' package work magic and conjure the
perfect configuration for any usecase, you could instead:

- add *good* documentation; with configuration examples, step-by-step
instructions to setup whatever additional service,...
- provide an *additional* package ("gitlab-to-go", but please cose a
better name :-)) which depends on 'gitlab' (and other packages like
'letsencrypt') and which does the magic to provide the "it just works"
experience for selected use-cases.

i really hope that this will simplify your work as a maintainer of such
a complex package. (or put otherwise: i think that the quest to come up
with a satisfying configuration for all potential users is NP-complete
and will indefinitely stall further packaging or make the package
unusable for some users or both)

a nice side effect might be that it would allow Debian gitlab packages
follow upstream more closely (e.g. Debian currently has
gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
series is at bugfix release 8.4.7; the numbers might be a bit misleading
though, as Debian might not be affected by a few bugs that triggered
there own bugfix release).


anyhow, thanks again for doing all the work to bring us gitlab.

fgmards
IOhannes


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: