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 :-) > 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. 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 -- Poki
pgpY3msKcTLPo.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
