[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Nate Graham <nate () kde ! org>
Date:       2019-02-25 19:17:48
Message-ID: 16926178151.104dbaabb40704.8754498062466094355 () kde ! org
[Download RAW message or body]

 ---- On Mon, 25 Feb 2019 09:54:26 -0700 Martin Flöser <mgraesslin@kde.org> wrote \
----   > You asked for comments. I gave comment that I'm not pleased about yet  
 > another transition. Please keep that in mind. It means learning and  
 > interrupted workflows for every one. If you have already decided and  
 > don't want anybody to point out that transitions are painful, please  
 > don't ask for comments. Instead say that sysadmins decided. That's at  
 > least honest - your reply gives me the feeling the decision is already  
 > done and negative feedback was not expected. Sorry to feel this way. 

I think it goes without saying that transitions are painful, so it doesn't seem \
necessary to point this out because it's obvious to anyone who's ever undergone a \
transition. The point of any transition is that the pleasure of the new system should \
outweigh the temporary pain involved in transitioning, and the permanent the pain \
imposed by the current system.

Like you, I have some reservations about Gitlab. I'm not thrilled about losing \
approve/request changes statuses (that's in the EE edition only right now). And \
gitlab's fork-the-repo workflow feels more awkward to me than Phab's patch-based \
workflow, and I have some questions regarding scalability and the kdesrc-build \
experience given that each of our 80+ frameworks has its own repo. There are also \
some UI issues associated with inline comments in merge requests that I'd like to see \
fixed.

But there is a lot of pain currently associated with Phab. Multi-commit chains are \
very difficult to do correctly. Updating patches to reflect changes in the origin is \
error-prone. The website's user interface and search are poor. Landing patches is \
time-consuming and error-prone. The review experience for patches that change SVG \
icons is terrible, and occasionally suffers from a bug that that makes certain \
patches impossible to review [1].

All of these issues are fixed with Gitlab in my experience testing our our evaluation \
instance on https://invent.kde.org.  Have you had a chance to try it out yet? I \
didn't notice any comments from you in \
https://notes.kde.org/p/gitlab-evaluation-notes

And I think there's value in listening to the outside world when people tell us that \
they prefer Gitlab's  workflow to Phab's system that attempts (and fails) to abstract \
away Git itself. The enormous popularity of Github means that this workflow is at the \
very least  familiar to a huge amount of developers, if not outright superior. If we \
ignore that, we risk losing newcomers over time because our system is just weird and \
awkward compared to the norm, no matter how good our documentation is--and I think \
it's pretty darn good right now.

And yes, the documentation will go stale and need to be updated. I'll do this for \
Gitlab just like I did for Phab [2].


[1] https://secure.phabricator.com/T1022
[2] https://community.kde.org/index.php?title=Infrastructure/Phabricator&action=history).



Nate


[prev in list] [next in list] [prev in thread] [next in thread]