Re: gitlab package (was Re: Opt out style recommends)
On 2016, ഏപ്രിൽ 10 12:28:29 AM IST, "IOhannes m zmölnig (Debian/GNU)" <email@example.com> wrote:
>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
I just want the service up and running after you install gitlab. Isn't it how every other service doing it?
>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.
It does not. Even earlier with letsencrypt in depends, it asks in post install if letsencrypt should be used. Now it is in recommends and you can just skip letsencrypt.
>there are a number of reasons to use the Debian gitlab packages over
>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).
It is just the first attempt and making all components optional is in my todo. Patches to speed it up is welcome.
nginx is already made optional in last update. Next is database.
>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
>not accessible from the public internet - something that is impossible
>with letsencrypt afaict).
Already covered. You can choose not to use letsencrypt.
>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
>(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
>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).
Making all components optional will do it.
And the configuration files are there to do more tweaking.
>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
>though, as Debian might not be affected by a few bugs that triggered
>there own bugfix release).
Its already 8.5.8. Three new gems are required for 8.6 and we are already working on it.
>anyhow, thanks again for doing all the work to bring us gitlab.
Sent from my Android device with K-9 Mail. Please excuse my brevity.