Kristoffer Gronlund <kgronl...@suse.com> wrote:
On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote:
Jan Pokorný <jpoko...@redhat.com> writes:
So GitLab has a problem that AFAIK even GitHub didn't have, where
certain crucial features are only in the enterprise edition -
You're portraying GitLab as worse than GitHub here, but your logic is
backwards ;-) *All* of GitHub's functionality is non-libre, whereas
only certain features of GitLab are.
though they did announce the special allowance for open source projects the
other day which I don't know the details of.
https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/
And of course GitLab risks being acquired not by Microsoft but whoever
else
http://uk.businessinsider.com/gitlab-raises-20-million-from-gv-2017-10
so again, not sure how much it improves. Unless self-hosting that
is.
No, you don't have to start with self-hosting for there to be a huge
difference between these two scenarios; this is comparing apples to
oranges. GitHub's code is not FLOSS; GitLab CE is.
Microsoft could in *theory* do something unspeakably evil with GitHub
*today* (although of course they won't, not yet at least). Whereas if
GitLab the company decided to say, radically increase their prices,
any users could migrate either to self-hosting, or to a rival GitLab
CE hosting company which would inevitably spring up to compete with
the original GitLab company. With GitHub, there is no nearly
identical equivalent to migrate to without significant disruption, and
there never will be as long as GitHub remains proprietary.
May I remind you that we both work on FLOSS for the same pure-FLOSS
company which was acquired multiple times ;-) And during or after
these acquisitions, none of the FLOSS projects sponsored by our
company somehow magically turned into evil proprietary technology.
Copyleft guarantees that that cannot happen.
Pagure has the benefit of being written in Python which I'm comfortable
with so yeah, maybe we can fix any problems with it ;)
"I'm comfortable with" ... "we can" - hmm, there is a gap in your
logic here, but I guess that's what the smiley was for ;-) But
seriously, even if we pretended you weren't already an experienced
Ruby developer, it would be easier for you as a Python-only dev to
learn Ruby and start hacking on GitLab CE, than to first bring Pagure
up to feature parity with GitLab CE. I'm not hugely familiar with
Pagure but it seems hugely under-powered in features compared to
GitLab. I'm really curious why it was decided to reinvent the wheel -
perhaps a misguided Python vs. Ruby thing? If it was only an ethical
objection to the GitLab's open core model then it would have been far
easier simply to fork the core.
In any case, this makes for interesting reading:
https://lwn.net/Articles/724986/
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.
Yes, Savannah is awful :-(
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").
Yes, this is *exactly* what GitHub gets so badly wrong and Gerrit gets
so right. I have already done a lot of work documenting this, e.g.
https://ethercalc.openstack.org/github-gerrit
https://github.com/isaacs/github/issues/997
https://github.com/isaacs/github/issues/998
https://github.com/isaacs/github/issues/999
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. :)
TL;DR: GitHub code review sucks horribly (the details can all be found
in https://github.com/isaacs/github/issues), whereas Gerrit doesn't.
And with heavy investment from Google, Gerrit is getting dangerously
close to being awesome. If you want to have a quick play with it,
take a look at
https://android-review.googlesource.com
or
https://review.gerrithub.io/
which is Gerrit providing code review on top of some GitHub repos.
(*Don't* look at the OpenStack Gerrit which is a very old version
missing the more recent total revamp of the UI.)
In the short term, I'd suggest concentrating on the two points I raised:
- good discipline regarding commit messages
- more systemic approach to release tarballs if possible
Both of these are generally good suggestions, I agree that we should
make an effort regarding commit messages.
+1
On the other hand, there is a
balance between having good commit messages and lowering the threshold
of contribution from outside developers.
Having bad commit messages raises the threshold of contribution for
*everyone*; please don't start down that slippery slope ;-)
https://wiki.openstack.org/wiki/GitCommitMessages
It's pretty easy to gently and politely help new contributors to
improve their commit messages to the point that they can be merged
without compromising on high standards. And in the process the new
contributors learn how to collaborate better. Everyone should be
given the opportunity to learn the ropes. Turning a blind eye to poor
quality doesn't help anyone.
_______________________________________________
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
