Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Scott Kruger]

On 2022-01-20 21:40, Junchao Zhang did write:
> *  Email notification when one is mentioned or added as a reviewer

Like Barry, I get emails on these so I think your notification settings
are off.

> *  Color text in comment box
> *  Click a failed job, run the job with the *updated* branch

I doubt that they will ever allow this because it would get to
complicated, but there are improvements to workflow that could be made.

Ideal workflow:
 - Automatically detects that this is a resubmit, and runs the last
   failed job first; i.e., if linux-cuda-double fails, run that job
   first, and then rerun the rest of the pipeline if it passes (so that
   we get a clean pipeline for the MR).

Current workflow (from Satish) which works but is a pain:
 - Launch pipeline.  Stop it.  Find job on web page and start it
   manually.  If passes, hit run on pipeline.

Less-ideal-but-improved workflow:
Based on what I've seen the team do with the `pages:` job (which I
learned about this week), this might work?

Add something like this to `.test`:

  only:
  variables:
- $PETSC_RUN_JOB == $TEST_ARCH

So that could then launch a pipeline with:
PETSC_RUN_JOB = arch-ci-linux-cuda
except I'm pretty sure this won't work based on how those `$`'s are
interpreted.  Thoughts, Satish?

Other-Less-ideal-but=improved workflow:
I tried playing around with setting variables related to tags when you
launch a job; e.g., 
   PETSC_JOB_TAG = gpu:nvidia

where `gpu:nvidia` is a current tag that I also tried to label a job in
other ways, but I couldn't get it to work (documentation made me think
we could do this.  This was a couple of years ago though, and perhaps
they have something like this working.



> *  Allow one to reorder commits (e.g., the fix up commits generated from
> applying comments) and mark commits that should be fixed up
> *  Easily retarget a branch, e.g., from main to release (currently I have
> to checkout to local machine, do rebase, then push)

This is making a git gui in gitlab (GitKraken, gitk, lazygit, etc.)  
No disagreement, but the workflow issues should take much higher priority IMO.

Scott

 
> --Junchao Zhang
> 
> 
> On Thu, Jan 20, 2022 at 7:05 PM Barry Smith  wrote:
> 
> >
> >   I got asked to go over some of my Gitlab workflow uses next week with
> > some Gitlab developers; they do this to understand how Gitlab is used, how
> > it can be improved etc.
> >
> >   If anyone has ideas on topics I should hit, let me know. I will hit them
> > on the brokenness of appropriate code-owners not being automatically added
> > to reviewers. And support for people outside of the Petsc group to set more
> > things when they make MRs. And being to easily add non-PETSc folks as
> > reviewers.
> >
> >   Barry
> >
> >

-- 
Scott Kruger
Tech-X Corporation   kru...@txcorp.com
5621 Arapahoe Ave, Suite A   Phone: (720) 466-3196
Boulder, CO 80303Fax:   (303) 448-7756

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[jacob.fai]

Almost forgot to mention, ask them if they can make popup-boxes (when e.g.
choosing a label, reviewers, etc) size dynamic or at the very least manually
resizable. The size is ok for smaller laptop screens, but only showing at
most 5 items in a 30+ item list on a larger screen with no way to make the
box bigger is a travesty.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391

| -Original Message-
| From: jacob@gmail.com 
| Sent: Friday, January 21, 2022 07:34
| To: 'Lawrence Mitchell' ; 'Barry Smith' 
| Cc: 'petsc-dev' 
| Subject: RE: [petsc-dev] Gitlab workflow discussion with GitLab developers
| 
| 1. Allow searching pipeline jobs by name, type, or tag. I want to be able
to
| find all "linux-cuda-double-64idx" jobs that ran in the last 24 hours, or
all jobs
| that have the tag gpu:nvidia for example. Currently I must manually click
| through the pages and snoop on everyone's pipelines. It would be nice if
the
| https://gitlab.com/petsc/petsc/-/jobs page had the same "filter"
| search box that pipelines have.
| 2. The filter pipelines needs to be able to search for "awaiting
approval".
| I like to cancel all the zombie jobs that MRs create due to
auto-pipelines,
| which so far I have done by manually checking my MRs after pushes.
| 
| Best regards,
| 
| Jacob Faibussowitsch
| (Jacob Fai - booss - oh - vitch)
| Cell: (312) 694-3391
| 
| | -Original Message-
| | From: petsc-dev  On Behalf Of
| Lawrence
| | Mitchell
| | Sent: Friday, January 21, 2022 04:32
| | To: Barry Smith 
| | Cc: petsc-dev 
| | Subject: Re: [petsc-dev] Gitlab workflow discussion with GitLab
| | developers
| |
| |
| | > On 21 Jan 2022, at 01:05, Barry Smith  wrote:
| | >
| | > I got asked to go over some of my Gitlab workflow uses next week
| | > with
| | some Gitlab developers; they do this to understand how Gitlab is used,
| | how it can be improved etc.
| | >
| | >  If anyone has ideas on topics I should hit, let me know. I will hit
| them on
| | the brokenness of appropriate code-owners not being automatically
| | added to reviewers. And support for people outside of the Petsc group
| | to set
| more
| | things when they make MRs. And being to easily add non-PETSc folks as
| | reviewers.
| |
| | At least in my experience reviewing large (by diffstat measures) in
| | the browser (I use Safari) is nigh-on unusable since the web interface
| | grinds
| to a
| | halt, and has various other bugs.
| |
| | Of course one should aim for small code changes that are easy to
| | review,
| but
| | often a small code change will produce large changes in the test
| | output
| files
| | (which have to appear in the MR, or else one merges broken code).
| |
| | Some examples, if I go to one of Jacob's recent cleanup MRs:
| | https://gitlab.com/petsc/petsc/-/merge_requests/4700/diffs
| |
| | Dragging the scroll bar is very laggy (I guess there's some background
| thread
| | trying to load things from somewhere?).
| |
| | Semi-randomly, if I click to add a comment on a change, the page jumps
| back
| | to the start and I lose my place.
| |
| | This seems slightly better in Brave (Chromium).
| |
| | I don't know enough about how the web interface/database integration
| | works, but grinding to a halt on a 6000 line diff is unfortunate.
| |
| | Lawrence

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Jed Brown]

When applying suggestions, it should offer to "instant fixup" (apply it to some 
prior commit in this branch, but not in any other branches). That instant fixup 
should highlight commits that changed nearby lines.

When you make an inline comment and the author changes those lines of code, it 
now offers to show you "these lines", but in my experience, it's usually the 
wrong lines. I think because it's showing the same line numbers, not the same 
context (and something had changed the number of lines earlier).

BTW, I submitted a request for open source project status not long ago (maybe a 
week) with intent to unlock some project management features (like Epics).

I kinda wish merge requests could be displayed in Boards. Sometimes we use 
draft MRs to track actual bugs (rather than start by making an issue, then 
linking the issue) and it'd be nice to have a board with MRs that have set 
release as a milestone, with columns for their workflow stage.

Their license detector doesn't recognize BSD-2-Clause. It shows "Other" on the 
home page, even when I tried removing the appended disclaimer about 
--download-package.

https://gitlab.com/petsc/petsc/

Barry Smith  writes:

>   I got asked to go over some of my Gitlab workflow uses next week with some 
> Gitlab developers; they do this to understand how Gitlab is used, how it can 
> be improved etc. 
>
>   If anyone has ideas on topics I should hit, let me know. I will hit them on 
> the brokenness of appropriate code-owners not being automatically added to 
> reviewers. And support for people outside of the Petsc group to set more 
> things when they make MRs. And being to easily add non-PETSc folks as 
> reviewers.
>
>   Barry

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[jacob.fai]

1. Allow searching pipeline jobs by name, type, or tag. I want to be able to
find all "linux-cuda-double-64idx" jobs that ran in the last 24 hours, or
all jobs that have the tag gpu:nvidia for example. Currently I must manually
click through the pages and snoop on everyone's pipelines. It would be nice
if the https://gitlab.com/petsc/petsc/-/jobs page had the same "filter"
search box that pipelines have. 
2. The filter pipelines needs to be able to search for "awaiting approval".
I like to cancel all the zombie jobs that MRs create due to auto-pipelines,
which so far I have done by manually checking my MRs after pushes.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391

| -Original Message-
| From: petsc-dev  On Behalf Of Lawrence
| Mitchell
| Sent: Friday, January 21, 2022 04:32
| To: Barry Smith 
| Cc: petsc-dev 
| Subject: Re: [petsc-dev] Gitlab workflow discussion with GitLab developers
| 
| 
| > On 21 Jan 2022, at 01:05, Barry Smith  wrote:
| >
| > I got asked to go over some of my Gitlab workflow uses next week with
| some Gitlab developers; they do this to understand how Gitlab is used, how
| it can be improved etc.
| >
| >  If anyone has ideas on topics I should hit, let me know. I will hit
them on
| the brokenness of appropriate code-owners not being automatically added
| to reviewers. And support for people outside of the Petsc group to set
more
| things when they make MRs. And being to easily add non-PETSc folks as
| reviewers.
| 
| At least in my experience reviewing large (by diffstat measures) in the
| browser (I use Safari) is nigh-on unusable since the web interface grinds
to a
| halt, and has various other bugs.
| 
| Of course one should aim for small code changes that are easy to review,
but
| often a small code change will produce large changes in the test output
files
| (which have to appear in the MR, or else one merges broken code).
| 
| Some examples, if I go to one of Jacob's recent cleanup MRs:
| https://gitlab.com/petsc/petsc/-/merge_requests/4700/diffs
| 
| Dragging the scroll bar is very laggy (I guess there's some background
thread
| trying to load things from somewhere?).
| 
| Semi-randomly, if I click to add a comment on a change, the page jumps
back
| to the start and I lose my place.
| 
| This seems slightly better in Brave (Chromium).
| 
| I don't know enough about how the web interface/database integration
| works, but grinding to a halt on a 6000 line diff is unfortunate.
| 
| Lawrence

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Lawrence Mitchell]

> On 21 Jan 2022, at 01:05, Barry Smith  wrote:
> 
> I got asked to go over some of my Gitlab workflow uses next week with some 
> Gitlab developers; they do this to understand how Gitlab is used, how it can 
> be improved etc. 
> 
>  If anyone has ideas on topics I should hit, let me know. I will hit them on 
> the brokenness of appropriate code-owners not being automatically added to 
> reviewers. And support for people outside of the Petsc group to set more 
> things when they make MRs. And being to easily add non-PETSc folks as 
> reviewers.

At least in my experience reviewing large (by diffstat measures) in the browser 
(I use Safari) is nigh-on unusable since the web interface grinds to a halt, 
and has various other bugs.

Of course one should aim for small code changes that are easy to review, but 
often a small code change will produce large changes in the test output files 
(which have to appear in the MR, or else one merges broken code).

Some examples, if I go to one of Jacob's recent cleanup MRs: 
https://gitlab.com/petsc/petsc/-/merge_requests/4700/diffs

Dragging the scroll bar is very laggy (I guess there's some background thread 
trying to load things from somewhere?).

Semi-randomly, if I click to add a comment on a change, the page jumps back to 
the start and I lose my place.

This seems slightly better in Brave (Chromium).

I don't know enough about how the web interface/database integration works, but 
grinding to a halt on a 6000 line diff is unfortunate.

Lawrence

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Patrick Sanan]

Very much agreed that the biggest sort of friction is dealing with MRs from
forks. I suspect that the reason many of the things we want don't work is
because they would be too dangerous to allow a random, possibly malicious,
user to do. E.g. setting labels seems innocuous enough, but all kinds of
workflows, including automated ones, could be based on them. A more likely
problem in our case is that someone could open an MR with
"workflow::Ready-to-Merge" because they guess that it means that from their
perspective it's ready (when to us it means more than that). It would be
easy for that to get merged before being reviewed.

So in asking about all this, maybe we should make sure that we understand
the privilege levels GitLab offers, as maybe we can address the usual case
that the outside person making an MR is a researcher or engineer that one
of us knows (of) and so has some degree of trust in, so there would be no
huge risk in giving them the ability to change labels etc.

(And my pet peeve is that my "todo list" is still swamped by "X set you as
an approver for Y".)

Am Fr., 21. Jan. 2022 um 06:53 Uhr schrieb Barry Smith :

>
>
> On Jan 20, 2022, at 10:40 PM, Junchao Zhang 
> wrote:
>
> *  Email notification when one is mentioned or added as a reviewer
>
>
>Hmm, I get emails on these? I don't get email saying I am code owner
> for a MR
>
> *  Color text in comment box
> *  Click a failed job, run the job with the *updated* branch
> *  Allow one to reorder commits (e.g., the fix up commits generated from
> applying comments) and mark commits that should be fixed up
> *  Easily retarget a branch, e.g., from main to release (currently I have
> to checkout to local machine, do rebase, then push)
>
> --Junchao Zhang
>
>
> On Thu, Jan 20, 2022 at 7:05 PM Barry Smith  wrote:
>
>>
>>   I got asked to go over some of my Gitlab workflow uses next week with
>> some Gitlab developers; they do this to understand how Gitlab is used, how
>> it can be improved etc.
>>
>>   If anyone has ideas on topics I should hit, let me know. I will hit
>> them on the brokenness of appropriate code-owners not being automatically
>> added to reviewers. And support for people outside of the Petsc group to
>> set more things when they make MRs. And being to easily add non-PETSc folks
>> as reviewers.
>>
>>   Barry
>>
>>
>

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Barry Smith]

> On Jan 20, 2022, at 10:40 PM, Junchao Zhang  wrote:
> 
> *  Email notification when one is mentioned or added as a reviewer

   Hmm, I get emails on these? I don't get email saying I am code owner for a MR

> *  Color text in comment box
> *  Click a failed job, run the job with the updated branch
> *  Allow one to reorder commits (e.g., the fix up commits generated from 
> applying comments) and mark commits that should be fixed up
> *  Easily retarget a branch, e.g., from main to release (currently I have to 
> checkout to local machine, do rebase, then push)   
> 
> --Junchao Zhang
> 
> 
> On Thu, Jan 20, 2022 at 7:05 PM Barry Smith  > wrote:
> 
>   I got asked to go over some of my Gitlab workflow uses next week with some 
> Gitlab developers; they do this to understand how Gitlab is used, how it can 
> be improved etc. 
> 
>   If anyone has ideas on topics I should hit, let me know. I will hit them on 
> the brokenness of appropriate code-owners not being automatically added to 
> reviewers. And support for people outside of the Petsc group to set more 
> things when they make MRs. And being to easily add non-PETSc folks as 
> reviewers.
> 
>   Barry
> 

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Junchao Zhang]

*  Email notification when one is mentioned or added as a reviewer
*  Color text in comment box
*  Click a failed job, run the job with the *updated* branch
*  Allow one to reorder commits (e.g., the fix up commits generated from
applying comments) and mark commits that should be fixed up
*  Easily retarget a branch, e.g., from main to release (currently I have
to checkout to local machine, do rebase, then push)

--Junchao Zhang


On Thu, Jan 20, 2022 at 7:05 PM Barry Smith  wrote:

>
>   I got asked to go over some of my Gitlab workflow uses next week with
> some Gitlab developers; they do this to understand how Gitlab is used, how
> it can be improved etc.
>
>   If anyone has ideas on topics I should hit, let me know. I will hit them
> on the brokenness of appropriate code-owners not being automatically added
> to reviewers. And support for people outside of the Petsc group to set more
> things when they make MRs. And being to easily add non-PETSc folks as
> reviewers.
>
>   Barry
>
>

Re: [petsc-dev] Gitlab workflow discussion with GitLab developers

[Matthew Knepley]

Hashes should work in the search box. Also, the searching in MRs is not
that accurate.

   Matt

On Thu, Jan 20, 2022 at 8:05 PM Barry Smith  wrote:

>
>   I got asked to go over some of my Gitlab workflow uses next week with
> some Gitlab developers; they do this to understand how Gitlab is used, how
> it can be improved etc.
>
>   If anyone has ideas on topics I should hit, let me know. I will hit them
> on the brokenness of appropriate code-owners not being automatically added
> to reviewers. And support for people outside of the Petsc group to set more
> things when they make MRs. And being to easily add non-PETSc folks as
> reviewers.
>
>   Barry
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

[petsc-dev] Gitlab workflow discussion with GitLab developers

[Barry Smith]

  I got asked to go over some of my Gitlab workflow uses next week with some 
Gitlab developers; they do this to understand how Gitlab is used, how it can be 
improved etc. 

  If anyone has ideas on topics I should hit, let me know. I will hit them on 
the brokenness of appropriate code-owners not being automatically added to 
reviewers. And support for people outside of the Petsc group to set more things 
when they make MRs. And being to easily add non-PETSc folks as reviewers.

  Barry