[ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?
jpokorny at redhat.com
Thu Jun 7 04:15:55 EDT 2018
On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote:
> Jan Pokorný <jpokorny at 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
>> 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
> 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,
> (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 :-)
> 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.
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers