Re: Gitlab Evaluation & Migration
On 2/26/19 4:17 AM, Nate Graham wrote: 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). Me too. It's one of the things we're asking to be moved to the CE -- and so is Gnome. GitLab knows we're talking to each other and doubling down on this need. > the kdesrc-build experience How would GitLab impact the kdesrc-build experience? > Landing patches is time-consuming and error-prone. Yes. As a maintainer of things I often land patches by new contributors without dev access, and it's super annoying and painful. `arc patch`, remember to correct author info, merge around, ... > Phab's system that attempts (and fails) to abstract away Git itself I think Phab was originally written for SVN - it shows I guess. Cheers, Eike
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:02 PM Eike Hein wrote: > > > > On 2/26/19 4:17 AM, Nate Graham wrote: > > 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). > > Me too. It's one of the things we're asking to be moved to the CE -- and > so is Gnome. GitLab knows we're talking to each other and doubling down > on this need. > > > > the kdesrc-build experience > > How would GitLab impact the kdesrc-build experience? > > > > Landing patches is time-consuming and error-prone. > > Yes. As a maintainer of things I often land patches by new contributors > without dev access, and it's super annoying and painful. `arc patch`, > remember to correct author info, merge around, ... > > > > Phab's system that attempts (and fails) to abstract away Git itself > > I think Phab was originally written for SVN - it shows I guess. I can confirm that Phabricator was originally written for SVN (as that is what is used internally at Facebook). The ability to have Phabricator host repositories was something it only gained around the time we started looking at migrating to it. Prior to that it had exclusively been a repository viewer and code review tool (and I suspect the code review part predates the repository viewer component) > > > Cheers, > Eike Cheers, Ben
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 5:54 AM Martin Flöser wrote: > > Am 2019-02-24 21:03, schrieb Ben Cooksley: > > On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser > > wrote: > >> > >> Am 2019-02-23 10:44, schrieb Ben Cooksley: > >> > Hi all, > >> > >> > Based on all of the above we'd like to propose migrating towards > >> > Gitlab. Comments? > >> > >> I'm totally honest here: I'm not happy about yet another migration. > >> This > >> will be the fifth reviewing toolkit I use for KDE (reviewboard for > >> svn, > >> reviewboard for git, gerrit, phabricator and now gitlab). Each of the > >> transitions was painful for everyone involved and the commit rate to > >> the > >> project I was involved suffered from the transitions. As an example > >> for > >> the problems: KWin's hacking document still mentions reviewboard: > >> https://community.kde.org/KWin/Hacking#Submitting_Changes > > > > Please don't over exaggerate the numbers here. > > > > Gerrit was never an official system for reviews, it was something that > > was evaluated by a small group and which was never proceeded with as > > an official whole-of-KDE solution. > > Reviewboard for SVN/Git are basically the same thing (just a different > > instance url), so this is only really the third system, not the fifth > > You missed the point. What I wrote is that the transitions were painful > - also the very simple transition from svn.reviewboard to > git.reviewboard was painful. That it was the same tool doesn't matter. > It was still a transition, it meant looking at two places, lost reviews, > update to documentation, change of workflow, etc. etc. > > Also gerrit was a tool I used for KDE hacking. I wrote it will be the > fifth toolkit for me. That's true for me and I don't over exaggerate any > numbers here. > > > > > Please also bear in mind that we've been on Git now for coming up on 9 > > years (I have mails for git.kde.org starting around June 2010) so > > switching systems twice in that time frame as software continues to > > mature seems quite reasonable to me. > > Please keep also in mind that the git transition took a long time and > started for different projects at different times. That you as sysadmin > had mails going back so long does not mean others as well. I consider it > as a transition too early after Phabricator was praised so much. I was > sure that this would be a solution for the next decade. > Unfortunately this has turned out not to be the case, due to changing needs of the community. > > > >> > >> I'm not pleased that we want to transit to another solution after just > >> a > >> few years. I understand that there is the feeling that our phabricator > >> solution limits contributions from newcomers. I don't believe that and > >> are afraid of the long term developers walking away due to the changes > >> (which is something I saw with every transition). I don't know whether > >> I > >> will continue to contribute if I have to relearn the tooling - my time > >> for KDE is currently very limited. If I have an hour to hack and have > >> to > >> spend half the time on how to contribute now, that sucks and lowers > >> motivation. > > > > If you've worked with Github before then Gitlab is very similar, so > > the learning curve shouldn't be too steep. > > I haven't worked with github. > > > > >> > >> Changing the tooling will not solve any of the contribution problems. > >> Instead we introduce new ones like all documentation going out of > >> life. > >> > >> Please consider whether the advantages are really worth it. > > > > Please also see my comments re. Phabricator upstream as to part of the > > reason why we're considering this, along with the feedback we received > > at Akademy last year. > > Well I remember how phabricator was praised for the very responsive > team. That seems to have changed. But who guarantees that gitlab will > continue to be responsive and cooperative? Will we have to switch again > if the team stops to be responsive? > > 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. Undertaking the process of transitioning from one tool to another is not something we do lightly, as it not only involves disruption for people who have to switch to a new set of tools, but also requires substantial changes to the infrastructure (I will note that Phabricator never took over hosting of our repositories) No decision has been made, that's what this thread is about. I may have my personal views on what may be best, but that's all they are - my views. > > Cheers > Martin Regards, Ben
Re: Gitlab Evaluation & Migration
On 2019-02-26 10:13, Ben Cooksley wrote: No decision has been made, that's what this thread is about. I may have my personal views on what may be best, but that's all they are - my views. I might be one of the few KDE contributors who actively likes phabricator, but I'm all for migrating. I've had a number of questions, but those have all been answered satisfactorily. * can new contributors without push access to the main repos still submit patches: yes * is our phabricator history safe: yes * I've seen one workboard per project, that's not ideal, otoh, the Krita community early on went overboard with workboards, so we can make do with that * it's possible to add images to issues, so the lack of mockups isn't that important -- we organized our mockups per task in any case I'm still not happy with how issue tracking and project management are conflated, but I guess I can live with that, as long as we keep bugzilla for user bug reports. We discussed this topic at yesterday's weekly Krita meeting, and everyone agreed that we are in favor of moving to gitlab. Boudewijn
Re: Gitlab Evaluation & Migration
On 2/26/19 6:26 PM, b...@valdyas.org wrote: * I've seen one workboard per project, that's not ideal, otoh, the Krita community early on went overboard with workboards, so we can make do with that I consider this one a blocker, and it's one of the things we've told GitLab we really want in the CE. Let's expand in on this. On Phab, we currently have boards like "Wayland" that contain issues from different projects. In the GitLab CE, it's currently only possible to have one board per project, and it's possible to put projects into a hierarchy. I.e. when all projects are sub-projects on a "KDE" one, it becomes possible to have a board at the "KDE" level that contains issues from different subprojects. But that means "Wayland" could be the only board, which is rubbish. I have every expectations we will get this. GitLab has once made public promise that they would not put arbitrary numeric limitations on the CE offering, and "one board per project" is an arbitrary numeric limitation vs. "as many boards as you want". Side note: GitLab also has a concept called "Epics" that's kind of like boards without the columns. We don't know yet, as a community, if we would use to use these and how, I guess, but they seem interesting. Boudewijn Cheers, Eike
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:26 PM wrote: > > On 2019-02-26 10:13, Ben Cooksley wrote: > > > No decision has been made, that's what this thread is about. > > I may have my personal views on what may be best, but that's all they > > are - my views. > > I might be one of the few KDE contributors who actively likes > phabricator, but I'm all for migrating. I've had a number of questions, > but those have all been answered satisfactorily. > > * can new contributors without push access to the main repos still > submit patches: yes > * is our phabricator history safe: yes > * I've seen one workboard per project, that's not ideal, otoh, the Krita > community early on went overboard with workboards, so we can make do > with that > * it's possible to add images to issues, so the lack of mockups isn't > that important -- we organized our mockups per task in any case > > I'm still not happy with how issue tracking and project management are > conflated, but I guess I can live with that, as long as we keep bugzilla > for user bug reports. At this time we do most definitely plan to keep Bugzilla for user bug reports. > > We discussed this topic at yesterday's weekly Krita meeting, and > everyone agreed that we are in favor of moving to gitlab. > > Boudewijn Cheers, Ben
Re: Gitlab Evaluation & Migration
On Sat, Feb 23, 2019 at 10:45 AM Ben Cooksley wrote: > > Hi all, > > [...] > > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? Good decision. Hopefully the migration will start sooner than later. Thank you for all your work on that.
Re: Gitlab Evaluation & Migration
Hello, On Sat, 23 Feb 2019, at 10:44, Ben Cooksley wrote: > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? Just a small FYI from the migration of the VideoLAN community. We're moving almost everything from git/gitosis, jenkins, trac, patchwork, mediawiki, gitweb to gitlab and gitlab-ci. We have projects that are very very classical (ML + Patches, with people using only mutt to read) to projects that are MR-only, with no mailing lists at all. So far, the model works for everyone. And the CI is a godsend, especially after working with jenkins. The only big downside, (besides some small bugs), is the bugtracker that is the usual "github issue" clone. Aka, not a bugtracker: no custom fields, no customization possible, horrible labeling system and people using it to track their issues (aka, I cannot read the documentation and read how to compile, which should be in the forum). So far, the gitlab team does not want to address those concerns, and will add the required features in the non-open source edition. The rest is great. Best, -- Jean-Baptiste Kempf - President +33 672 704 734
Re: Gitlab Evaluation & Migration
On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt wrote: > > On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote: > > > * Is there anything we can have that can replace tasks and workboards? We > > usually have some very long-running tasks that get a lot of sub-tasks and > > that basically document our development process. One thing I've learned > > with Phabricator is that project planning and issue tracking have nothing > > to do with each other. > > Another thing here: what would be a good way to keep the really valuable > information we've put in our tasks available? We have been tracking some big > projects in phab's task system, and that information would be really hard to > lose, but it would also rather suck to have to convert that manually to wiki > pages or whatever... I suppose I could be persuaded to migrate all tasks again ;) As Eike mentioned the current boards feature is fairly limited though, so that may complicate things (a lot). HS
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:37 AM Eike Hein wrote: > > > > On 2/26/19 6:26 PM, b...@valdyas.org wrote: > > * I've seen one workboard per project, that's not ideal, otoh, the Krita > > community early on went overboard with workboards, so we can make do > > with that > > I consider this one a blocker +1
Re: Gitlab Evaluation & Migration
On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein wrote > How would GitLab impact the kdesrc-build experience? So this is the current kdesrc-build experience: 1. kdesrc-build [thing] 2. cd ~/kde/src[thing] 3. arc feature my-awesome-patch 4. Start hacking 5. kdesrc-build --no-src --resume-from [thing] 6. [test and make sure it works] 7. arc diff --create It's really pretty nice. But Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request. Since Merge Requests from people without commit access have to come from a private fork, that means that in the above model, they need to use some web UI to first create a private fork, and then somehow tell kdesrc-build to check that out rather than the original repo. Alternatively, perhaps kdesrc-build could check out the source from the original repo, but automatically create a second remote in each repo that corresponds to the private fork? Then people could hack in the original repo, but push their branches to the private remote fork for the purposes of creating a Merge Request. All of this is probably technically solvable, but it seems like it will take some doing to ensure that the user experience is as good as it currently is today (IMO, of course!). Nate
Re: Building KDE statically
On Fri, Feb 22, 2019 at 11:57:42AM +0800, Jonathan Schultz wrote: > Hello KDE developers, > > If anyone is interested, here is a brief report on something I have been > working on in my spare time. > > TLDR: Here are some scripts to build KDE frameworks and okular statically > using gcc/musl and cross-building for mingw: > https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see > the interesting stuff. Jonathan, This is really cool! I agree that it would be good to start with frameworks-devel since I think if we were to pick up some of this work at all, it would be best for us to start with KF5 and ensure that we can get a "KF5 static" version setup in our CI infrastructure before we'd start working on adding support for static build to applications. You're right that kdesrc-build doesn't support cross-build... at all. I'm impressed you convinced stock kdesrc-build to make this work, even with pre-built executables. Have you looked into things like Snap or Flatpak at all as a way to ease deployments? Or is this meant to be a bit more crossplatform (Linux, macOS, Windows)? Regards, - Michael Pyne
