Re: On the need to move to a merge request workflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 26, 2020 at 15:50:20 +0000, Daniel Berrange wrote:
> On Thu, Mar 26, 2020 at 02:10:59PM +0100, Peter Krempa wrote:
> > On Fri, Mar 06, 2020 at 11:44:07 +0000, Daniel Berrange wrote:
> > > We've discussed the idea of replacing our mailing list review workflow with
> > > a merge request workflow in various places, over the last 6 months or so,
> > 
> > One thing I feel the need to voice until this is taken in place is a
> > matter of personal preference:
> > 
> > I severely dislike the merge request workflow and I'll be severely
> > disappointed once we switch over to it.
> 
> Can you elaborate on specific things you don't like, so we can see if
> there are any options to mitigate them ?

- it's a web page
    - it's very slow on big projects and slow in general
    - it's ugly, "theme" support is a joke, white background burns my
      eyes
    - it works badly on a portrait display
    - mangles commit messages in an attempt to render them (link and
    signed-off line concatenated:
    https://gitlab.com/libvirt/libvirt/-/commit/e05dd1abdc3b3eeac6e12ab105e56138d783af2a


- usability
    - default view after opening a branch is "Files" not "commits"
    - web interface doesn't really carry information about which merge
      requests are new to me

- review is terrible
    - threads are only single level
    - response can't be quoted (okay, they can but you have to copy and
      pase what you want to quote and then select that it's a quote)
    - you need to click to see the code
    - comments to code are in proportional font
    - a lot of useless clutter in the UI
    - need to click open comments in code
    - extra steps necessary to apply code locally (granted you get a
      branch by default, but fetching it is not as easy as I have with
      mail workflow)
    - review process favours review without actually fetching the code
      locally (if you can click a button, who will actually test that
      the code works?)


Now I know you will suggest I try your 'bichon' tool for reviews as it
fixes a handful of the problems outlined above, but unfortunately that
comes with it's own set of problems since it's in infancy stage.

In addition with current upstream bug tracker and discussions at least
being delivered using email I have notifications about new stuff even if
I have to interact with a web page. Bichon doesn't seem to want to deal
with 'issues' section at all.

That means that I'll have to trade a process that works very well for me
for using either a  web page with many problems of it's own or aleviate
some of the problems to  command line tool which is being developed
rapidly and thus likely to break often. And some of the problems are not
addressed by either, e.g. quoting parts of comments.

All together this will be a substantial downgrade for me and thus I'm
unhappy.





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux