From: Laszlo Ersek <lersek@redhat.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: stephano <stephano.cetola@linux.intel.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Ruiyu Ni" <ruiyu.ni@intel.com>
Subject: GitLab results from my POV [was: Research Request]
Date: Wed, 12 Dec 2018 14:20:24 +0100 [thread overview]
Message-ID: <2ed6d9d8-95f9-8d96-5811-7cd7013e0a99@redhat.com> (raw)
In-Reply-To: <4330857f-4e27-632f-6f82-6fc6ec636b2e@linux.intel.com>
Hi,
On 11/14/18 19:34, stephano wrote:
> We are currently researching several different options to help make
> contributing to TianoCore easier for the community. A big part of this
> effort will be enabling pull requests and allowing for a more
> customizable code review process.
>
> I am looking for members of the community willing to answer a few
> questions about these solutions to allow us to evaluate our options
> quickly. The options are:
>
> System/Tool Investigator
> Phabricator Rebecca Cran (thank you again :) )
> Github ???
> Gerrit ???
> Gitlab ???
>
> I have a list of questions that I can send out to each investigator.
> Assuming you are familiar with the software/system, these questions
> should be answerable with a couple hours of research, writing, and
> screenshots / examples.
>
> Thanks in advance for your help!
So Phil and I worked on evaluating GitLab. Phil opened a merge request
(MR#2) at <https://gitlab.com/philmd/edk2-platforms/merge_requests/2>,
and we used that for the evaluation. It was a multi-patch series. Here's
how it went.
(1) I couldn't make comments tied to the commit messages of the patches.
I could make generic comments on the merge request itself. I could also
make code location-tied comments on the individual commits. So this was
a mixed result.
(2) The WebUI is incredibly resource hungry, in my Firefox setup anyway.
Even while just scrolling the diffs with the mouse wheel, one CPU of my
laptop was pegged at 100%, and the visual response lagged *hugely* after
my manual mouse actions. This affected "alt text" displays for icons,
and clicking icons/buttons as well. It was so annoying it made me *not*
want to look at the subject patch set at all, just so I could stop
dealing with the UI.
(3) I managed to figure out a way for fetching the topic branch that was
pending review / the merge request. So that was good.
(4) Once Phil force-pushed a non-ff update, the old branch head was lost
in the sense that (a) it was apparently no longer "named" by anything,
(b) I could no longer refer to the v1 history on a commit-by-commit
basis, only as a cumulative diff. First, I could only compare the
cumulative diffs between v1 and v2. Second, my v1 comments lost their
contexts -- they were displayed near the code snippets where I had made
them, but they were no longer connected to individual commits. I found
this extremely confusing -- basically, the commit boundaries and the
discussion contexts were lost for v1.
(5) I received *zero* emails about my own actions, and I couldn't figure
out where I could change that. (In GitHub at least there's an obscure
setting that can be toggled -- Brian Johnson told me about that, thanks
again.)
(6) As I was about to add another comment to MR#2, Phil did something
(I'm unsure what -- maybe the action was the opening of MR#3?) that
killed MR#2 altogether. All the comments, even the MR#2 summary, were
lost. The first symptom that made me notice this was that when I clicked
the "Comment" button under MR#2, GitLab complained that there must have
been a network error, because saving the comment failed. In reality MR#2
had been killed by then -- I realized that when I attempted to reload
MR#2 in full. See
<https://gitlab.com/philmd/edk2-platforms/merge_requests/3>.
Note that the above summary may be incomplete. Due to a combination of
(5) and (6), that is, due to no emails of my own actions and due to MR#2
vanishing without a trace, I can't re-read our discussion in MR#2.
Quite unintentionally, this ended up being *splendid* evidence why I
absolutely insist on a complete email audit trail.
If I missed various aspects of GitLab (which is quite likely), please do
educate me. I don't mean to say that everyone else should stop
investigating GitLab -- perhaps more seasoned GitLab users can fill the
potholes I fell into.
After having looked at GitHub, Phabricator, and GitLab, my personal
preference remains the mailing list. A *distant* second is GitHub.
(GitHub is "almost there", but its emails significantly lack context.)
And Phabricator and GitLab just don't cut it for me; Phabricator doesn't
map to multi-patch series to begin with, and GitLab is too resource
hungry, and it did a terrible job (for me anyway) preserving history.
Can someone setup Gerrit for a test drive?...
(Honestly, at this point, I'm slightly scared/prejudiced of what I might
find there.)
Thanks,
Laszlo
next prev parent reply other threads:[~2018-12-12 13:20 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 18:34 [edk2-announce] Research Request stephano
2018-11-20 23:47 ` Jeremiah Cox
2018-11-21 0:58 ` stephano
2018-11-26 21:43 ` Jeremiah Cox
2018-11-26 22:27 ` stephano
2018-11-27 9:33 ` Knop, Ryszard
2018-11-27 21:16 ` Jeremiah Cox
2018-11-27 22:23 ` Rebecca Cran
2018-11-28 18:19 ` Jeremiah Cox
2018-11-28 19:21 ` Rebecca Cran
2018-11-27 12:53 ` Laszlo Ersek
2018-11-27 21:55 ` Brian J. Johnson
2018-11-28 11:07 ` Laszlo Ersek
2018-11-28 18:31 ` Jeremiah Cox
2018-11-28 22:01 ` Laszlo Ersek
2018-11-29 1:07 ` Jeremiah Cox
2018-11-29 9:48 ` Laszlo Ersek
2018-11-29 21:20 ` Rebecca Cran
2018-12-03 9:29 ` Laszlo Ersek
2018-12-03 21:39 ` Rebecca Cran
2018-12-04 18:00 ` Laszlo Ersek
2018-12-05 12:55 ` Laszlo Ersek
2018-12-05 17:26 ` Rebecca Cran
2018-12-06 14:05 ` Laszlo Ersek
2018-12-06 14:07 ` Laszlo Ersek
2018-12-06 14:13 ` Laszlo Ersek
2018-12-06 15:25 ` Rebecca Cran
2018-12-07 6:10 ` Rebecca Cran
2018-12-07 12:00 ` my Phabricator findings [was: Research Request] Laszlo Ersek
2018-12-07 13:11 ` Rebecca Cran
2018-12-05 17:31 ` [edk2-announce] Research Request Rebecca Cran
2018-12-06 13:51 ` Laszlo Ersek
2018-12-03 17:22 ` Jeremiah Cox
2018-12-04 18:26 ` Laszlo Ersek
2018-12-05 19:09 ` Jeremiah Cox
2018-12-06 13:33 ` Laszlo Ersek
2018-11-28 5:54 ` Desimone, Nathaniel L
2018-11-28 6:22 ` Stephano Cetola
2018-12-04 18:20 ` Philippe Mathieu-Daudé
2018-12-05 16:03 ` stephano
2018-12-12 13:20 ` Laszlo Ersek [this message]
2018-12-20 17:46 ` GitLab results from my POV [was: Research Request] Rebecca Cran
2019-01-10 20:17 ` about 'sr.ht' " Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ed6d9d8-95f9-8d96-5811-7cd7013e0a99@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox