On 2018-06-07 08:58, Kristoffer Grönlund wrote:
Jan Pokorný <jpoko...@redhat.com> writes:
On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote:
Jan Pokorný <jpoko...@redhat.com> writes:
But with the latest headlines on where that site is likely headed,
I think it's a great opportunity for us to possibly jump on the
bandwagon inclined more towards free (as in freedom) software
principles.
Possible options off the top of my head:
- GitLab, pagure: either their authoritative sites or self-hosted
- self-hosted cgit/whatever
It would also allow us to reconsider our workflows, e.g. using
gerrit
for patch review queue (current silent force-pushes is a horrible
scheme!).
My general view is that I also feel (and have felt) a bit uneasy
about
free software projects depending so strongly on a proprietary
service. However, unless self-hosting, I don't see how f.ex. GitLab
is
much of an improvement
Open-core business approach aside as perhaps necessary downside at
these scales, the difference is crucial: Community Edition is open
source, anyone can host it individually, which is what enabled
both Debian and GNOME to consider it's usage (became a reality
for the latter: https://gitlab.gnome.org/explore/groups,
https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/)
Feature-wise:
https://wiki.debian.org/Alioth/GitNext/GitLab
https://wiki.debian.org/Alioth/GitNext
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/FeatureMatrix
(Pagure might be a different story, but does it offer a comparable
user experience?) in that regard, and anything hosted on "public"
cloud is basically the same. ;)
Pagure has the benefit you can influence it relatively easily, as
I directly attested :-)
So GitLab has a problem that AFAIK even GitHub didn't have, where
certain crucial features are only in the enterprise edition - though
they did announce the special allowance for open source projects the
other day which I don't know the details of.
And of course GitLab risks being acquired not by Microsoft but whoever
else, so again, not sure how much it improves. Unless self-hosting that
is.
Pagure has the benefit of being written in Python which I'm comfortable
with so yeah, maybe we can fix any problems with it ;)
crmsh used to be hosted at GNU Savannah, which is Free with a capital
F,
but the admin experience, user experience and general discoverability
in
the world at large all left something to be desired.
In regard to workflows, if everyone agrees, we should be able to
improve
that without moving. For example, if all changes went through pull
requests, there is a "required reviews" feature in github. I don't
know
if that is something everyone want, though.
https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
AFAIK this doesn't address the qualitative complaint I have. It makes
for a very poor experience when there's no readily available way to
observe evolution of particular patchsets, only to waste time of the
reviewer or contribute to oversights ("I'll skip this part I am sure
I reviewed already, if there was a generational diff, I'd have a look,
but the review is quite a pain already, I'll move on").
No, setting up a bot to gradually capture work in progress is not
a solution. And pull-request-per-patchset-iteration sounds crazy
considering this count sometimes goes pretty high.
I'll confess that I have no experience with Gerrit or the Github
required reviews, and I don't really know how they differ. :)
Adding some info as these are things I know something about.
Gitlab & Github are very similar, but I much prefer Gitlab after having
used both.
For open-source projects Gitlab gives you all features, including things
like "approvers" for merge-requests. They have a nice permission model
which allows only some users to approve merge requests and to set a
minimum number of approvers.
The fundamental unit of review in Gitlab is the merge-request,
requesting that a branch be merged into another. This works very well in
practice. You can configure a regex for branch names and only allow
users to push to branches with a prefix like "contributions/", making
all other branches "protected", i.e. prevent direct pushes.
The code-review is good, but could be better. Every time you update the
branch (either amending a commit or pushing a new commit) this creates a
new "version" of the merge-request that you can diff against previous
versions. The bad thing here is that comments are not always carried
over as they should be. There is also no way of marking a file as
reviewed, so large reviews can be cumbersome. The good news is that this
stuff is improving slowly.
Gerrit is a much more powerful tool for code-review. The workflow is
less intuitive however and has a far higher learning curve. It requires
specific hooks to be installed to work well and works by a "patch-set"
concept. You push your changes to a "for" branch, i.e. "for-master" and
they then end up on an unnamed branch on the server in a review. From
there they can be pulled and tested.
The code-review is top-notch, with comments attached to a version of the
patch-set and intra-version diffs being quick and elegant.
The negative sides of Gerrit typically outweigh the positive for most
organizations I'm afraid:
- No central hosting like gitlab.com.
- High threshold for new contributors (unusual workflow, hooks needed. )
- No bugs/issues etc. But good jira integration.
I haven't tried pagure. There is also gitea which looks promising. And
bitbucket.
/Nils
_______________________________________________
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
