4 ms·
we'd have to carry our own internal fork of Gitlab So you have the choice between buying Gitlab or coding yourself. You would prefer it to be free and without
by ttoinou 8y ago
we'd have to carry our own internal fork of Gitlab
So you have the choice between buying Gitlab or coding yourself. You would prefer it to be free and without hassle, but lack to see everything has a cost.
- bubblethink 8y agoThat's not OP's main point. It's that even if they implement it (as in a clean room), there is no chance of it being merged upstream. Now, if the OP implements some entirely different feature not related to gitlab's pricing, it can be merged upstream in the CE. This is in contrast to conventional open source projects.
- rndgermandude 8y agouh, a lot of patches to open source get rejected for all kinds of reasons, incl code quality, being off topic or just because the maintainers (irrationally) dislike the patches. GNU emacs (or more specically RMS) rejected patches that would integrate clang, or provided colorful emoji support on OSX, for political reasons, and that's perfectly fine for a project to do. Gitlab will reject some patches for business political reasons, which is also perfectly fine. If you don't like that, fork. If a lot of people don't like it, then the fork becomes effectively the new upstream (e.g. GCC/ecgs). There is no "Right to have my patch merged" anyway.
- deleted 8y ago[deleted]