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
signature.asc
Description: OpenPGP digital signature