On 07/06/18 11:10 +0000, Nils Carlson wrote:
> On 2018-06-07 08:58, Kristoffer Grönlund wrote:
>> Jan Pokorný <jpoko...@redhat.com> writes:
>>> 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.I must admit, this would be a killer feature for me (see the above rant) and best trade-off if the willingness to try/adopt Gerrit is unlikely. > 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. Thanks for sharing your thoughts, Nils, appreciated. P.S. Your post may be stuck in the moderation queue, hopefully this is resolved soon (as a rule of thumb, I recommend subcribing to particular list first if not already, but there can be additional anti-spam measures for first-time/unrecognized posters). -- Poki
pgpJ29F73cJD9.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
