Re: GitLab postmortem
On Sun, 2018-12-23 at 17:21 +, Philip Withnall wrote: > On Wed, 2018-12-19 at 16:48 +, Philip Withnall wrote: > > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > > Hey, > > > > It has been a few months since we moved to GitLab. Apart of > > > > spurious issues, specific annoyances and frustrations, seems it > > > > has been generally good. I would like to gather some general > > > > feeling about it. Things that really made a constant impact to > > > > you and your work, both bad or good. Feel free to provide > > > > feedback about the transition or the administration of GitLab > > > > instance too. Free form. > > > > > > It’s all been pretty excellent. I can’t fault the transition or > > > the effort that people have put into it. > > > > > > A few larger annoyances about GitLab, having now worked with it > > > for a while: > > To follow up on these, I’ve now filed bugs for some of them. See > below: > > > > 1. Being able to draft review comments and submit them all at > > > once would reduce e-mail overload on people, and make it easier > > > to draft coherent code reviews. I quite like how GitHub does this > > > (although I dislike most other things about GitHub). > > Paid-for feature. ☹ > > > > 2. Hiding the diff of a large file when it’s the only file > > > changed in an MR is not helpful. I should file a bug about this. > > I can’t currently find the MR I saw this with, but will file an issue > with GitLab if I see it again. I really should have filed it when I > first saw the problem, sorry. > > > > 4. Starting to type while the tag popover is loading will still > > > execute global hotkeys, which normally refreshes the page or does > > > something unexpected. I should file a bug about this too. > > Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55679. > > > > 5. Changing branches when creating an MR loses your > > > title/description/tags, and since the branch drop-down is quite > > > far down the form, I often forget to do that first before filling > > > out the title/description/tags. This makes backports a bit more > > > annoying. I should file a bug about this too. > > Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55680. > > > > 6. GitHub recently acquired a way to suggest minor one-line > > > changes to MRs, and allow the MR author to press a button to > > > accept them. This would be really good for minor typo fixes and > > > cleanups. It would be less intrusive than having to write a > > > nitpick comment for each one and making the MR author really > > > bored or frustrated with the review. > > Apparently we just got this with 11.6. Looking forward to trying it > out! > > > 7. The ability for a maintainer to push fixups to an old MR, or > > rerun failed CI pipelines on it, so that we don’t have to clone MRs > > to resurrect ones where the original author has wandered off; and > > people don’t have to remember to tick the “allow others to push to > > my branch” tickbox when creating an MR to allow the CI pipelines to > > be retried. > > There already seems to be an upstream issue about it: > https://gitlab.com/gitlab-org/gitlab-ce/issues/55680. That was a copy/paste error. I actually meant this link for #7: https://gitlab.com/gitlab-org/gitlab-ce/issues/49323 Sorry,Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list wrote: > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > 3. I’d like to see continued movement towards disallowing direct > > pushes to git, and requiring all commits to go through MRs (and > > CI). > > Hi, > I hope this won't go through without a good research and reasoning. I only care that the option is available for each maintainer to disallow direct pushes; not that the policy is applied to all modules. > Any such requirement would be kind of showstopper for me personally. > It > would be just double work for me when coding (issue is not merge > request), causing awful commit history, resulting in unbelievably > harder effort required to produce NEWS file content (yes, I do use > commit messages to fill the NEWS files in a semi-automated way saving > my time, which I can spend on more productive things). To name a few > major obstacles at least. I’ve just written this script for generating a NEWS entry from `git log` plus information from GitLab, which you might find useful: https://gitlab.gnome.org/pwithnall/gitlab-changelog Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 15 Jan 2019, at 10:04, Bastien Nocera wrote: > On Tue, 2019-01-15 at 10:58 +0100, Emilio Pozuelo Monfort wrote: > > It should still be easy to fork the project, push a branch to your > > namespace, > > and then submit a MR. Or did I misunderstand? > > Too many trips to the web browser, too many re-clones of the repo (or > esoteric git command-lines), and too many left-over repos in your own > namespace. It's a problem I have with github as well, it's the same > workflow. I have found the 'hub' and 'lab' tools very useful for avoiding trips to the web browser. https://github.com/github/hub https://github.com/zaquestion/lab ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2019-01-15 at 10:58 +0100, Emilio Pozuelo Monfort wrote: > On 15/01/2019 10:48, Bastien Nocera wrote: > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > Hey, > > > > > > It has been a few months since we moved to GitLab. Apart of > > > spurious > > > issues, specific annoyances and frustrations, seems it has been > > > generally good. I would like to gather some general feeling about > > > it. > > > Things that really made a constant impact to you and your work, > > > both > > > bad or good. Feel free to provide feedback about the transition > > > or > > > the administration of GitLab instance too. Free form. > > > > > > Please keep the mail chain one way from you towards the world, so > > > we > > > don't get trapped on specifics, we can address stuff raised here > > > individually out of list. Personally, I'll ping you on IRC or so > > > if I > > > can do something to help. > > > > > > Of course, feel free to msg me directly on IRC/email too. > > > > My main problem is/was that contributing by pushing a branch is > > super- > > easy, but you can't contribute by pushing a branch if you're not > > allowed to push a branch. So this isn't a problem when you're in > > @GNOME, and the project is as well, but I've not bothered pushing > > small > > fixes to non-GNOME group modules. > > It should still be easy to fork the project, push a branch to your > namespace, > and then submit a MR. Or did I misunderstand? Too many trips to the web browser, too many re-clones of the repo (or esoteric git command-lines), and too many left-over repos in your own namespace. It's a problem I have with github as well, it's the same workflow. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On 15/01/2019 10:48, Bastien Nocera wrote: > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: >> Hey, >> >> It has been a few months since we moved to GitLab. Apart of spurious >> issues, specific annoyances and frustrations, seems it has been >> generally good. I would like to gather some general feeling about it. >> Things that really made a constant impact to you and your work, both >> bad or good. Feel free to provide feedback about the transition or >> the administration of GitLab instance too. Free form. >> >> Please keep the mail chain one way from you towards the world, so we >> don't get trapped on specifics, we can address stuff raised here >> individually out of list. Personally, I'll ping you on IRC or so if I >> can do something to help. >> >> Of course, feel free to msg me directly on IRC/email too. > > My main problem is/was that contributing by pushing a branch is super- > easy, but you can't contribute by pushing a branch if you're not > allowed to push a branch. So this isn't a problem when you're in > @GNOME, and the project is as well, but I've not bothered pushing small > fixes to non-GNOME group modules. It should still be easy to fork the project, push a branch to your namespace, and then submit a MR. Or did I misunderstand? Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > Hey, > > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been > generally good. I would like to gather some general feeling about it. > Things that really made a constant impact to you and your work, both > bad or good. Feel free to provide feedback about the transition or > the administration of GitLab instance too. Free form. > > Please keep the mail chain one way from you towards the world, so we > don't get trapped on specifics, we can address stuff raised here > individually out of list. Personally, I'll ping you on IRC or so if I > can do something to help. > > Of course, feel free to msg me directly on IRC/email too. My main problem is/was that contributing by pushing a branch is super- easy, but you can't contribute by pushing a branch if you're not allowed to push a branch. So this isn't a problem when you're in @GNOME, and the project is as well, but I've not bothered pushing small fixes to non-GNOME group modules. Per-commit reviews are absolutely head-against-the-desk because the UI is really bad, and the diff tool is sluggish. I miss splinter if I have more than one commit to review. All-in-all, it's still a better, and known, workflow for people who didn't want to, or couldn't learn about git-bz, and having a CI available is awesome. Don't even need to spend a second reviewing patches that don't build ;) Good job :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
Now that it has settled down, thanks all for the feedback! It's really useful for me (and I believe for everyone else) to have a general feeling and what things are in common as biggest struggles and positives. Cheers On Wed, 2 Jan 2019 at 16:22, Germán Poo-Caamaño wrote: > On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list > wrote: > > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > > 3. I’d like to see continued movement towards disallowing direct > > > pushes to git, and requiring all commits to go through MRs (and > > > CI). > > > > Hi, > > I hope this won't go through without a good research and reasoning. > > > > Any such requirement would be kind of showstopper for me personally. > > It would be just double work for me when coding (issue is not merge > > request), causing awful commit history, resulting in unbelievably > > harder effort required to produce NEWS file content (yes, I do use > > commit messages to fill the NEWS files in a semi-automated way saving > > my time, which I can spend on more productive things). To name a few > > major obstacles at least. > > The history would be the same if you set up the Merge Request for your > project as "Fast-forward merge". > > >"No merge commits are created and all merges are fast-forwarded, >which means that merging is only allowed if the branch could be >fast-forwarded. >When fast-forward merge is not possible, the user is given the >option to rebase." > > I do also generate the NEWS file from the git history, and it is not > any different after having that change (which I did as soon as it was > possible to do). > > FWIW, I do both, direct commit and MR. The former for quick commits, > and the latter if someone can jump in to review them. > > > > I also cannot imagine any such thing enabled for 'work-in-progress' > > branches. That would be awful for any porting/cleanup/larger efforts. > > Try to not break master, and merge once the CI passes. That is the > point. > > I have seen one corner case, which required to update the CI first. > Also, you can let the CI fail without blocking the MR (exceptionally or > when it is a secondary issue) > > -- > Germán Poo-Caamaño > http://calcifer.org/ > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list wrote: > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > 3. I’d like to see continued movement towards disallowing direct > > pushes to git, and requiring all commits to go through MRs (and > > CI). > > Hi, > I hope this won't go through without a good research and reasoning. > > Any such requirement would be kind of showstopper for me personally. > It would be just double work for me when coding (issue is not merge > request), causing awful commit history, resulting in unbelievably > harder effort required to produce NEWS file content (yes, I do use > commit messages to fill the NEWS files in a semi-automated way saving > my time, which I can spend on more productive things). To name a few > major obstacles at least. The history would be the same if you set up the Merge Request for your project as "Fast-forward merge". "No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. When fast-forward merge is not possible, the user is given the option to rebase." I do also generate the NEWS file from the git history, and it is not any different after having that change (which I did as soon as it was possible to do). FWIW, I do both, direct commit and MR. The former for quick commits, and the latter if someone can jump in to review them. > I also cannot imagine any such thing enabled for 'work-in-progress' > branches. That would be awful for any porting/cleanup/larger efforts. Try to not break master, and merge once the CI passes. That is the point. I have seen one corner case, which required to update the CI first. Also, you can let the CI fail without blocking the MR (exceptionally or when it is a secondary issue) -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > 3. I’d like to see continued movement towards disallowing direct > pushes to git, and requiring all commits to go through MRs (and CI). Hi, I hope this won't go through without a good research and reasoning. Any such requirement would be kind of showstopper for me personally. It would be just double work for me when coding (issue is not merge request), causing awful commit history, resulting in unbelievably harder effort required to produce NEWS file content (yes, I do use commit messages to fill the NEWS files in a semi-automated way saving my time, which I can spend on more productive things). To name a few major obstacles at least. I also cannot imagine any such thing enabled for 'work-in-progress' branches. That would be awful for any porting/cleanup/larger efforts. So while any such thing would make perfect sense to anyone else, it doesn't fit to everyone. On the other hand, if I'm the only one... Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2018-12-19 at 16:48 +, Philip Withnall wrote: > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > Hey, > > > It has been a few months since we moved to GitLab. Apart of > > > spurious issues, specific annoyances and frustrations, seems it > > > has been generally good. I would like to gather some general > > > feeling about it. Things that really made a constant impact to > > > you and your work, both bad or good. Feel free to provide > > > feedback about the transition or the administration of GitLab > > > instance too. Free form. > > > > It’s all been pretty excellent. I can’t fault the transition or the > > effort that people have put into it. > > > > A few larger annoyances about GitLab, having now worked with it for > > a while: To follow up on these, I’ve now filed bugs for some of them. See below: > > 1. Being able to draft review comments and submit them all at once > > would reduce e-mail overload on people, and make it easier to draft > > coherent code reviews. I quite like how GitHub does this (although > > I dislike most other things about GitHub). Paid-for feature. ☹ > > 2. Hiding the diff of a large file when it’s the only file changed > > in an MR is not helpful. I should file a bug about this. I can’t currently find the MR I saw this with, but will file an issue with GitLab if I see it again. I really should have filed it when I first saw the problem, sorry. > > 4. Starting to type while the tag popover is loading will still > > execute global hotkeys, which normally refreshes the page or does > > something unexpected. I should file a bug about this too. Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55679. > > 5. Changing branches when creating an MR loses your > > title/description/tags, and since the branch drop-down is quite far > > down the form, I often forget to do that first before filling out > > the title/description/tags. This makes backports a bit more > > annoying. I should file a bug about this too. Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55680. > > 6. GitHub recently acquired a way to suggest minor one-line > > changes to MRs, and allow the MR author to press a button to accept > > them. This would be really good for minor typo fixes and cleanups. > > It would be less intrusive than having to write a nitpick comment > > for each one and making the MR author really bored or frustrated > > with the review. Apparently we just got this with 11.6. Looking forward to trying it out! > 7. The ability for a maintainer to push fixups to an old MR, or rerun > failed CI pipelines on it, so that we don’t have to clone MRs to > resurrect ones where the original author has wandered off; and people > don’t have to remember to tick the “allow others to push to my > branch” tickbox when creating an MR to allow the CI pipelines to be > retried. There already seems to be an upstream issue about it: https://gitlab.com/gitlab-org/gitlab-ce/issues/55680. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
Hi, On Wed, Dec 19, 2018 at 04:48:57PM +, Philip Withnall wrote: >7. The ability for a maintainer to push fixups to an old MR, or rerun >failed CI pipelines on it, so that we don’t have to clone MRs to resurrect >ones where the original author has wandered off; and people don’t have to >remember to tick the “allow others to push to my branch” tickbox when >creating an MR to allow the CI pipelines to be retried. >Philip Having the “allow others to push to my branch” on by default would already help a lot in this regard. Having "Remove source branch when merge request is accepted" as something in my user settings configurable would be awesome too (I should also file a bug here). Thanks a lot for the awesome GNOME gitlab/ci. -- Guido > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
I would say things have been fantastic from the engagement team perspective. I think the engagement team is more accessible now that we are using the same system as the rest of GNOME. We are able to project management ourselves and overall more efficient. I don't think we are using gitlab at a level that we can offer suggestions on improvement as we are primarily just using the issues feature. Anyone else on the engagement team should chime in if my views aren't a complete representation of the engagement team. :) sri On Fri, 2018-12-21 at 13:07 +, Allan Day wrote: > Hey Carlos, > > The GitLab transition has been really positive from a design > perspective. I would definitely say that our work feels easier and > more productive than it was. I think that GitLab is also helping us > to > maintain a healthy design team. > > Some highlights: > > - It's allowed us to migrate all our repos from GitHub back to GNOME > infrastructure, where they belong. > - Just having formatting and screenshots in issues makes a huge > difference, and make it much easier to have conversations about > design. We've actually started using issue tracking against our > mockup > repositories, which makes a lot of sense and is a good way to have > exploratory design discussions before engaging developers. > - Another thing I've found is that we've become more willing to > create repos, which is really useful for experimentation. > - Having a team space with all our repos is fantastic from a > team/community perspective. > - Being able to view diffs between image commits is great (although > this not new to us, because we were using GitHub before). > > Areas for improvement - the ability to have discussions in relation > to > mockups is limited - you can only comment on a single commit, not on > an image file or a set of image files. It's awkward referring to > mockups from issues (do you embed the mockup in the issue, link to > the > latest commit, or link to the file?) Ideally I'd want to mention the > mockup file and have GitLab take care of the rest - show a preview, > but also indicate if the image has changed since the comment was > posted. > > Allan > > On Tue, 11 Dec 2018 at 13:23, Carlos Soriano > wrote: > > Hey, > > > > It has been a few months since we moved to GitLab. Apart of > > spurious issues, specific annoyances and frustrations, seems it has > > been generally good. I would like to gather some general feeling > > about it. Things that really made a constant impact to you and your > > work, both bad or good. Feel free to provide feedback about the > > transition or the administration of GitLab instance too. Free form. > > > > Please keep the mail chain one way from you towards the world, so > > we don't get trapped on specifics, we can address stuff raised here > > individually out of list. Personally, I'll ping you on IRC or so if > > I can do something to help. > > > > Of course, feel free to msg me directly on IRC/email too. > > > > Thanks all! > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
Hey Carlos, The GitLab transition has been really positive from a design perspective. I would definitely say that our work feels easier and more productive than it was. I think that GitLab is also helping us to maintain a healthy design team. Some highlights: - It's allowed us to migrate all our repos from GitHub back to GNOME infrastructure, where they belong. - Just having formatting and screenshots in issues makes a huge difference, and make it much easier to have conversations about design. We've actually started using issue tracking against our mockup repositories, which makes a lot of sense and is a good way to have exploratory design discussions before engaging developers. - Another thing I've found is that we've become more willing to create repos, which is really useful for experimentation. - Having a team space with all our repos is fantastic from a team/community perspective. - Being able to view diffs between image commits is great (although this not new to us, because we were using GitHub before). Areas for improvement - the ability to have discussions in relation to mockups is limited - you can only comment on a single commit, not on an image file or a set of image files. It's awkward referring to mockups from issues (do you embed the mockup in the issue, link to the latest commit, or link to the file?) Ideally I'd want to mention the mockup file and have GitLab take care of the rest - show a preview, but also indicate if the image has changed since the comment was posted. Allan On Tue, 11 Dec 2018 at 13:23, Carlos Soriano wrote: > > Hey, > > It has been a few months since we moved to GitLab. Apart of spurious issues, > specific annoyances and frustrations, seems it has been generally good. I > would like to gather some general feeling about it. Things that really made a > constant impact to you and your work, both bad or good. Feel free to provide > feedback about the transition or the administration of GitLab instance too. > Free form. > > Please keep the mail chain one way from you towards the world, so we don't > get trapped on specifics, we can address stuff raised here individually out > of list. Personally, I'll ping you on IRC or so if I can do something to help. > > Of course, feel free to msg me directly on IRC/email too. > > Thanks all! > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > Hey, > > It has been a few months since we moved to GitLab. Apart of > > spurious issues, specific annoyances and frustrations, seems it has > > been generally good. I would like to gather some general feeling > > about it. Things that really made a constant impact to you and your > > work, both bad or good. Feel free to provide feedback about the > > transition or the administration of GitLab instance too. Free form. > > It’s all been pretty excellent. I can’t fault the transition or the > effort that people have put into it. > > A few larger annoyances about GitLab, having now worked with it for a > while: > > 1. Being able to draft review comments and submit them all at once > would reduce e-mail overload on people, and make it easier to draft > coherent code reviews. I quite like how GitHub does this (although I > dislike most other things about GitHub). > > 2. Hiding the diff of a large file when it’s the only file changed > in an MR is not helpful. I should file a bug about this. > > 3. I’d like to see continued movement towards disallowing direct > pushes to git, and requiring all commits to go through MRs (and CI). > I think the remaining barrier to this is the translation > workflow/Damned Lies. It would be good to get Damned Lies to create > MRs with submitted translation changes, so that it doesn’t need > direct push access to git, and so that translators don’t have to faff > with MRs themselves. > > 4. Starting to type while the tag popover is loading will still > execute global hotkeys, which normally refreshes the page or does > something unexpected. I should file a bug about this too. > > 5. Changing branches when creating an MR loses your > title/description/tags, and since the branch drop-down is quite far > down the form, I often forget to do that first before filling out the > title/description/tags. This makes backports a bit more annoying. I > should file a bug about this too. > > 6. GitHub recently acquired a way to suggest minor one-line changes > to MRs, and allow the MR author to press a button to accept them. > This would be really good for minor typo fixes and cleanups. It would > be less intrusive than having to write a nitpick comment for each one > and making the MR author really bored or frustrated with the review. 7. The ability for a maintainer to push fixups to an old MR, or rerun failed CI pipelines on it, so that we don’t have to clone MRs to resurrect ones where the original author has wandered off; and people don’t have to remember to tick the “allow others to push to my branch” tickbox when creating an MR to allow the CI pipelines to be retried. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > Hey, > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been > generally good. I would like to gather some general feeling about it. > Things that really made a constant impact to you and your work, both > bad or good. Feel free to provide feedback about the transition or > the administration of GitLab instance too. Free form. It’s all been pretty excellent. I can’t fault the transition or the effort that people have put into it. A few larger annoyances about GitLab, having now worked with it for a while: 1. Being able to draft review comments and submit them all at once would reduce e-mail overload on people, and make it easier to draft coherent code reviews. I quite like how GitHub does this (although I dislike most other things about GitHub). 2. Hiding the diff of a large file when it’s the only file changed in an MR is not helpful. I should file a bug about this. 3. I’d like to see continued movement towards disallowing direct pushes to git, and requiring all commits to go through MRs (and CI). I think the remaining barrier to this is the translation workflow/Damned Lies. It would be good to get Damned Lies to create MRs with submitted translation changes, so that it doesn’t need direct push access to git, and so that translators don’t have to faff with MRs themselves. 4. Starting to type while the tag popover is loading will still execute global hotkeys, which normally refreshes the page or does something unexpected. I should file a bug about this too. 5. Changing branches when creating an MR loses your title/description/tags, and since the branch drop-down is quite far down the form, I often forget to do that first before filling out the title/description/tags. This makes backports a bit more annoying. I should file a bug about this too. 6. GitHub recently acquired a way to suggest minor one-line changes to MRs, and allow the MR author to press a button to accept them. This would be really good for minor typo fixes and cleanups. It would be less intrusive than having to write a nitpick comment for each one and making the MR author really bored or frustrated with the review. Ta,Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On the whole, I'm really pleased with GitLab. Especially really pleased with the ability to start discussions during reviews and mark comments as resolved. It's a bit of a shame we can't batch comments like on GitHub, but marking discussions as resolved is amazing and makes up for it. The biggest problem by far has been Bugzilla migration. We still have tons of modules (e.g. gnome-shell, gnome-weather, geary, gsettings-desktop-schemas... just a few off the top of my head) which have still not completed Bugzilla migration. The very slow pace of migration is quite frustrating. Also, Bugzilla is quite broken right now, so you have to use Andre's direct links to get to the patch queue, bug list, etc. This would be a lot less frustrating once issues migrate, but in the meantime makes working with these modules almost impractical. Finally, it's just annoying to split discussion between Bugzilla and GitLab based on the time an issue was filed, or between patches and merge requests, for example. I know it's a huge pain to do these migrations, but at least it's just a one-time cost and then we can be fully moved to GitLab. On Tue, Dec 11, 2018 at 5:06 PM, Christian Hergert wrote: We have issue templates (although I haven't figured out how to set them up for my projects), but not issue reply templates. The issue templates are borderline useless though, because the ability to set a template as the default issue template is an EE feature. This means nobody ever looks at them. I tried these briefly but wound up removing them. I really want to be able to show users a short message or issue template before they report bugs I really need reply templates to keep up with the number of bugs I need to close after creation for a number of reasons. * Dups * Fixed in master, branch * Out of scope * User support * Feature requests (I take note of requests, but we do not hold bugs open, they only influence our roadmap). Failure to have reply templates results in grumpier replies from yours truly. I really miss these canned replies too. It's just a small annoyance, but it would be nice to have. Lacking some EE features is disappointing, but still, GitLab CE is much better than I was expecting. I'm very happy with how this has turned out (asides from the bug migrations). Apologies for my initial skepticism years ago. :) Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On 12/11/18 5:22 AM, Carlos Soriano wrote: > > Please keep the mail chain one way from you towards the world, so we > don't get trapped on specifics, we can address stuff raised here > individually out of list. Personally, I'll ping you on IRC or so if I > can do something to help. We have issue templates (although I haven't figured out how to set them up for my projects), but not issue reply templates. I really need reply templates to keep up with the number of bugs I need to close after creation for a number of reasons. * Dups * Fixed in master, branch * Out of scope * User support * Feature requests (I take note of requests, but we do not hold bugs open, they only influence our roadmap). Failure to have reply templates results in grumpier replies from yours truly. -- Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
Le mardi 11 décembre 2018 à 14:22 +0100, Carlos Soriano a écrit : > Hey, > It has been a few months since we moved to GitLab. Apart of spurious issues, > specific annoyances and frustrations, seems it has been generally good. I > would like to gather some general feeling about it. Things that really made a > constant impact to you and your work, both bad or good. Feel free to provide > feedback about the transition or the administration of GitLab instance too. > Free form. > > Please keep the mail chain one way from you towards the world, so we don't > get trapped on specifics, we can address stuff raised here individually out > of list. Personally, I'll ping you on IRC or so if I can do something to help. > > Of course, feel free to msg me directly on IRC/email too. 1. No Cross-Project CI supportIt's a bit off topic, as GStreamer is on FDO now. But the one thing that had hit was how complex the CI deployment across multiple projects (repository is). We really miss the pipeline aggregation on trigger that exist in the EE version. The side effect, builds are scattered across all repo, instead of being centrealized on the specific build system repo (in our case cerbero and gst-build). So looking over all builds is near impossible. The caches are always cold, because the build is too scattered. So all in all, what I really miss is that ability to trigger another project (repository) pipeline and gain an aggregated pipeline. With Jenkins, it fully centralized, hence much simplier, but still, now we can per commit CI, which is great. 2. No multi-commit codec review workflow Unlike github, there is no fluid way to navigate through each commits one by one during the review. The stack of commit is also upside down for a review. I generally endup opening commit in browser tabs, but that's not idea. Note that this is probably not a regression from bugzilla, but I was surprise to find out how inferior this is in gitlab in contrast to gihub. > Thanks all! > > ___desktop-devel-list mailing > listdesktop-devel-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
Hey Carlos, thanks for bringing this topic to the table. I certainly have feedback to share! Wall of text, tl;dr: GitLab is great, but could be greater; increased number of contributions, but not contributors; better tools to manage issues, but lacks project and product management features; needs better cli tools. Overall, my experience since the introduction of GitLab has been great so far. It is, without a doubt, a huge improvement over Bugzilla + cgit. The first impact it had on the projects I maintain is the massively increased number of contributions. Calendar and To Do are smaller apps, but saw an increase of around 2x the number of external contributions. Settings is a bigger app, and since I took over maintainership and instituted a shared maintainership model, the number of merge requests skyrocketed - to the point of becoming hard to keep track of it. I still haven't decided if this is a positive or negative aspect. I'm afraid this might have a negative impact on some high-bandwidth-but-on-maintainer-shortage modules, like GNOME Shell. I mean, even on Settings, when I see that there are *goddamn 30* open merge requests, I silently freak out. The influx of *contributions*, not *contributors*, increased, and there is a price we pay for that: more time spent on review means less time spent on coding. On top of that, I have to say, even though GitLab's issue management is fantastic for individual tickets, there is still a long road for mass managing tickets. It's still a PITA to mass label or change milestones of tickets. Feature-wise, GitLab is good enough, but as I expressed on IRC multiple times, I'm somewhat pissed off with their decision of not CE-ing some features (related tickets, multiple reviewers, etc). Specifically about reviewers, as it is right now, the feature is useless. On single-maintainer projects, nobody assigns that field because there's only one someone that will check that. On multiple-maintainer projects, the field is misleading since the merge request will probably be reviewed by more than a single someone. As Christian said in the past, GitLab lacks project and product management tools. Milestones are okay, but they could be so much more useful than they are right now. But my expectations are low due to the multiple disappointments regarding EE-ing important and useful features and leaving CE helpless. Em ter, 11 de dez de 2018 às 11:23, Carlos Soriano escreveu: > Hey, > > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been generally > good. I would like to gather some general feeling about it. Things that > really made a constant impact to you and your work, both bad or good. Feel > free to provide feedback about the transition or the administration of > GitLab instance too. Free form. > > Please keep the mail chain one way from you towards the world, so we don't > get trapped on specifics, we can address stuff raised here individually out > of list. Personally, I'll ping you on IRC or so if I can do something to > help. > > Of course, feel free to msg me directly on IRC/email too. > > Thanks all! > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2018-12-11 at 14:29 +0100, Alberto Fanjul Alonso via desktop- devel-list wrote: > It was a huge improvement. Now is really easy for many different > skilled > people to contribute. > > > I just miss a good global code search, (which I use all the time in > similar services to check real usages of gtk or vala for example) I second this one. So far, I search on https://github.com/GNOME/ but it would be nice to do it on Gitlab. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
It was a huge improvement. Now is really easy for many different skilled people to contribute. I just miss a good global code search, (which I use all the time in similar services to check real usages of gtk or vala for example) I miss to be able to include chunks of code with an URL or markdown tag in issue comments Appart from that, all feels great El mar., 11 dic. 2018 14:23, Carlos Soriano escribió: > Hey, > > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been generally > good. I would like to gather some general feeling about it. Things that > really made a constant impact to you and your work, both bad or good. Feel > free to provide feedback about the transition or the administration of > GitLab instance too. Free form. > > Please keep the mail chain one way from you towards the world, so we don't > get trapped on specifics, we can address stuff raised here individually out > of list. Personally, I'll ping you on IRC or so if I can do something to > help. > > Of course, feel free to msg me directly on IRC/email too. > > Thanks all! > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
