Re: [RFC] Tying in github issues into our workflow

On Wed, Aug 19, 2020 at 8:42 PM Neal Gompa [off-list ref] wrote:

On Wed, Aug 19, 2020 at 4:37 PM Josef Bacik [off-list ref] wrote:

quoted

Hello,

As we discussed last week, we'd really like to have a way to better track the
status of outstanding patches.  One of the suggestions Dave made was to use the
"Projects" feature inside github, because we're not going to be able to get away
from having patches on the mailinglist any time soon.

I've mocked up a couple of helper scripts and some documentation on how this
would work.  I've tested the workflow (not with real patches yet because my
develbox is down for maintenance ATM) and it seems reasonable and pretty
straightforward.  There are two scripts

https://github.com/josefbacik/debug-scripts/blob/master/btrfs-send-patches
https://github.com/josefbacik/debug-scripts/blob/master/btrfs-create-issue

I'll explain my thought process and such here, but if you don't care and just
want to look at the workflow then skip to the PREREQUISITES section at the bottom.

The project exists here

https://github.com/orgs/btrfs/projects/1

and has a few columns.  When we submit patches we'll create an issue and it'll
go into "Needs review".  This is straightforward, we're waiting on reviews for
these patches.  From here it's a little manual unfortunately, but once the
patches are reviewed you can move the issue to "Ready to be merged", and from
there Dave can decide if he's actually going to merge it.  If he does then he
can close the issue and it moves to the "Merged" state.  If he has comments he
can make those and move it to "Needs work".  Likewise if any reviewer has
comments then the issue can be moved to "Needs work" by the reviewer.

To reiterate we're not getting away from mailinglist interactions (yet), so we
should keep all patch related discussion on the list for now, we simply use
these issues so patch series don't get lost.  This will also help reviewers know
what is left to be reviewed.

Let me know what everybody (preferably just those of us who actually write
kernel patches) thinks about this.  None of this is set in stone, trying to work
out the easiest way to help track patch review status.  Thanks,

Josef

PREREQUISITES

You need to have the github cli tools installed, you can find packages for them here

https://github.com/cli/cli/releases

YOU MUST INSTALL THIS ON A BOX THAT CAN OPEN A WEB BROWSER.  This is important
because the first time you run the gh command it sets up the 0auth stuff, so it
must be able to open a browser.  The steps are

1) Install the gh package
2) run `gh repo view`.  This will launch the browser to do the 0auth stuff,
    follow the prompts.
3) [OPTIONAL] If you are like me and submit from a headless machine, you need to
    copy the ~/.config/gh/hosts.yaml file to the machine you are going to use,
    and everything will work fine.

WORKFLOW

DEVELOPER

1) The --thread option with git format-patch is is required for this to work
    with the tools I've written

    For a patch series: mkdir patches; git format-patch --thread -o patches -#
    For a single patch: git format-patch --thread -1

2) ./btrfs-send-patches <patches|0001-<whatever.patch>

    This does the git-send-email (which will ask you questions) and then creates
    the issue with the Message-Id that was generated with the appropriate links.

3) If you get feedback and your reviewer doesn't move the task to "Needs work"
    please do that, and then address any feedback.  Once the feedback is
    addressed you can change the issue to "Needs review" and update the
    description with the new Message-id information.

REVIEWER

1) Check the project page

    https://github.com/orgs/btrfs/projects/1

    for anything in the "Needs review column".  Review those patches on the list.

2a) If you are satisfied, change the status of the issue to "Ready to be merged"
     by dragging it into that column.  Alternatively, if you are in the issue
     itself, you can click the drop-down menu under the "Projects" section on the
     right and assign it to "Ready to be merged".

2b) If you have feedback, move the issue to the "Needs work" column in the same
     way as described above.

DAVE/MAINTAINER

1) Anything in the "Ready to be merged" is what you care about, do what you
    want.  If you merge it, close the task and it'll be automatically moved to
    "Merged", otherwise kick it back to whichever stage is appropriate.

I know you said that you principally wanted feedback from the btrfs
kernel hackers, but from someone who does the oddball thing here and
there and is trying to become increasingly active in btrfs upstream, I
have some thoughts here.

In general, I like the idea of moving to more contemporary workflows
for some parts of this stuff. I had actually been contemplating
setting up such a thing on pagure.io for tracking my own work on this
front (since I generally prefer to use FOSS platforms if I can).
Regardless of using GitHub.com or something else, I think it's a good
idea to have some generally usable way for tracking development and
allowing people to report issues to the project.

(It's a shame that kernel.org doesn't have a pagure instance. That
could be potentially more usable for a lot more people than the
oft-ignored and unloved bugzilla system, projects don't have to enable
pull requests with pagure projects, and all project metadata is stored
as git repositories, which I think would appeal to a lot of folks
here...)

By the way, in case anyone is interested in seeing my setup as I
populate it, here it is: https://pagure.io/fedora-btrfs/project

The project board is here:
https://pagure.io/fedora-btrfs/project/boards/Development

It maps to issues tagged with "Dev":
https://pagure.io/fedora-btrfs/project/issues?tags=Dev



-- 
真実はいつも一つ！/ Always, there's only one truth!