5 ms·

nice. the problem i have with gitlab is not much the upgrage process anymore, but the fact that you don't accept push requests from the community of features th

nice. the problem i have with gitlab is not much the upgrage process anymore, but the fact that you don't accept push requests from the community of features that you implemented in the enterprise edition. for example the git hook stuff. i hope someone who has the time and the skills forks gitlab and merges push requests of new features, even if they are already implemented in your pay-for version.

sytse 12y ago
Can you link to the merge request you refer to? Merging something depends on the quality of the implementation and the use case. We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.
- y0ghur7_xxx 12y ago
  > We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits. Seems like you sad exactly that a while ago: "We are unlikely to merge this functionality in CE because there already is a nice implementation in EE."¹ It's your repo. You can do whatever you want with it, no need to merge PR for features that are already in your EE edition. That's why I hope someone forks it, or something better comes around. ¹https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-41883889 https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-...
  - sytse 12y ago
    Thanks for the link. In the lines before the quote I said "This PoC still leaves a lot of work. Right now the controller writes files, this should be done though gitlab-shell." We where unlikely to merge it because the code quality was low, if someone makes a good implementation we're more open to merging it. BTW The pull request in question uses the git hooks to do code linting. I think it is a better user experience to do this in GitLab CI in parallel with the rest of your tests https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/
    - y0ghur7_xxx 12y ago
      > We where unlikely to merge it because the code quality was low Oh, so it's not because "there already is a nice implementation in EE." Ok. It's also in disagreement with what you sad on the EE announcement: "If the community develops code for a feature that is already in EE we will certainly consider merging it or open sourcing the EE feature. This depends on several factors including the seriousness of the merge request, the number of GitLab users requesting this feature and if the feature is useful for small and medium size organizations."¹ For at least this particular feature the community is clearly interested (just by looking at the +1 on the github issue), but you continue to handle the CE version as "demo" software for EE. Which is ok. Just say so clearly. ¹https://about.gitlab.com/2013/07/22/announcing-gitlab-enterprise-edition/#comment-972699115 https://about.gitlab.com/2013/07/22/announcing-gitlab-enterp...
      - sytse 12y ago
        Hi y0ghur7_xxx, I think the comment you just quoted is the most extensive and the best thing I've written about this. All my other comments are shorter versions of that comment in my mind. The CE version is not demo or crippleware. It is a fully functioning version of GitLab without any restrictions that is just as performant and secure as the EE version. The only difference is that the EE version has more features.
      - coldtea 12y ago
        >Oh, so it's not because "there already is a nice implementation in EE." Ok That they said "there already is a nice implementation in EE" doesn't automatically mean they also intended it to remain EE-specific forever. It could be also be read as "we won't merge this in the free edition, as we already have a nice implementation in EE we might merge later".
mrmondo 12y ago
I agree with this actually - the whole public Gitlab CE vs EE repos and management is a bit of a mess - it seems to be getting better though.

sytse 12y ago

Can you link to the merge request you refer to? Merging something depends on the quality of the implementation and the use case. We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.

y0ghur7_xxx 12y ago
> We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits. Seems like you sad exactly that a while ago: "We are unlikely to merge this functionality in CE because there already is a nice implementation in EE."¹ It's your repo. You can do whatever you want with it, no need to merge PR for features that are already in your EE edition. That's why I hope someone forks it, or something better comes around. ¹https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-41883889 https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-...
- sytse 12y ago
  Thanks for the link. In the lines before the quote I said "This PoC still leaves a lot of work. Right now the controller writes files, this should be done though gitlab-shell." We where unlikely to merge it because the code quality was low, if someone makes a good implementation we're more open to merging it. BTW The pull request in question uses the git hooks to do code linting. I think it is a better user experience to do this in GitLab CI in parallel with the rest of your tests https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/
  - y0ghur7_xxx 12y ago
    > We where unlikely to merge it because the code quality was low Oh, so it's not because "there already is a nice implementation in EE." Ok. It's also in disagreement with what you sad on the EE announcement: "If the community develops code for a feature that is already in EE we will certainly consider merging it or open sourcing the EE feature. This depends on several factors including the seriousness of the merge request, the number of GitLab users requesting this feature and if the feature is useful for small and medium size organizations."¹ For at least this particular feature the community is clearly interested (just by looking at the +1 on the github issue), but you continue to handle the CE version as "demo" software for EE. Which is ok. Just say so clearly. ¹https://about.gitlab.com/2013/07/22/announcing-gitlab-enterprise-edition/#comment-972699115 https://about.gitlab.com/2013/07/22/announcing-gitlab-enterp...
    - sytse 12y ago
      Hi y0ghur7_xxx, I think the comment you just quoted is the most extensive and the best thing I've written about this. All my other comments are shorter versions of that comment in my mind. The CE version is not demo or crippleware. It is a fully functioning version of GitLab without any restrictions that is just as performant and secure as the EE version. The only difference is that the EE version has more features.
    - coldtea 12y ago
      >Oh, so it's not because "there already is a nice implementation in EE." Ok That they said "there already is a nice implementation in EE" doesn't automatically mean they also intended it to remain EE-specific forever. It could be also be read as "we won't merge this in the free edition, as we already have a nice implementation in EE we might merge later".

mrmondo 12y ago

I agree with this actually - the whole public Gitlab CE vs EE repos and management is a bit of a mess - it seems to be getting better though.