4 ms·

I, for one, am very impressed by the capability of this (mostly-remote, IIRC) team to ship so many releases, so fast. We have now one release per month! We hos

by jbk 8y ago

I, for one, am very impressed by the capability of this (mostly-remote, IIRC) team to ship so many releases, so fast. We have now one release per month! We host most VideoLAN projects on our own instance, and the updates are now very smooth, especially compared to the beginning. Of course, there are features that we care about a lot and are not implemented, because they don't consider them important (or maybe not worth their time, which I understand) but it's a very solid software. I hope it can replace our wiki and bugtracker soon...

sytse 8y ago
Awesome that your upgrades are smooth, thanks for posting. We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/ https://about.gitlab.com/culture/remote-only/ And we do want to make sure that all the features you really need are there. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.
- jbk 8y ago
  > We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/ https://about.gitlab.com/culture/remote-only/ That's very hard to keep at a constant pace. > And we do want to make sure that all the features you really need are there. So far, everything is great, but we would love to have: - Custom Fields, in order to leave trac (such a pain, this service is); - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice; - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). (Btw, we currently use jenkins and we will move to gitlab-ci.)
  - AsyncAwait 8y ago
    > A way to fork/MR across Gitlab/Github instances I think ActivityPub would be a good fit for federation across GitLab instances and would have a real chance to displace Github for open-source projects, if implemented right.
    - ChristianBundy 8y ago
      Hell, git-ssb is already working! ActivityPub would be great for GNU Social or Mastodon (or, of course, Pleroma), but I still have a soft spot for Scuttlebutt.
    - Vinnl 8y ago
      There's this proposal issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/44486 https://gitlab.com/gitlab-org/gitlab-ce/issues/44486
  - matteeyah 8y ago
    Thanks for sharing more info about this jbk. > - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice; We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations. > - Custom Fields, in order to leave trac (such a pain, this service is); This one's on our radar as well - https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 > - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.
  - jchw 8y ago
    >- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). Although not identical, it's worth noting that GitLab tracks all versions of MRs throughout the life of an MR. So, if you force push, you can compare the MR before and after the force push, via the "Changes" tab. I could be wrong, but I believe this is actually a leg up on what GitHub provides.

by jbk 8y ago

sytse 8y ago

Awesome that your upgrades are smooth, thanks for posting. We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/ https://about.gitlab.com/culture/remote-only/ And we do want to make sure that all the features you really need are there. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.

jbk 8y ago
> We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/ https://about.gitlab.com/culture/remote-only/ That's very hard to keep at a constant pace. > And we do want to make sure that all the features you really need are there. So far, everything is great, but we would love to have: - Custom Fields, in order to leave trac (such a pain, this service is); - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice; - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). (Btw, we currently use jenkins and we will move to gitlab-ci.)
- AsyncAwait 8y ago
  > A way to fork/MR across Gitlab/Github instances I think ActivityPub would be a good fit for federation across GitLab instances and would have a real chance to displace Github for open-source projects, if implemented right.
  - ChristianBundy 8y ago
    Hell, git-ssb is already working! ActivityPub would be great for GNU Social or Mastodon (or, of course, Pleroma), but I still have a soft spot for Scuttlebutt.
  - Vinnl 8y ago
    There's this proposal issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/44486 https://gitlab.com/gitlab-org/gitlab-ce/issues/44486
- matteeyah 8y ago
  Thanks for sharing more info about this jbk. > - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice; We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations. > - Custom Fields, in order to leave trac (such a pain, this service is); This one's on our radar as well - https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 > - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.
- jchw 8y ago
  >- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). Although not identical, it's worth noting that GitLab tracks all versions of MRs throughout the life of an MR. So, if you force push, you can compare the MR before and after the force push, via the "Changes" tab. I could be wrong, but I believe this is actually a leg up on what GitHub provides.