[RFC] Tying in github issues into our workflow

[RFC] Tying in github issues into our workflow

[Josef Bacik]

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.

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

[Neal Gompa]

On Wed, Aug 19, 2020 at 4:37 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> 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...)



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

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

[Neal Gompa]

On Wed, Aug 19, 2020 at 8:42 PM Neal Gompa <ngompa13@gmail.com> wrote:
>
> On Wed, Aug 19, 2020 at 4:37 PM Josef Bacik <josef@toxicpanda.com> wrote:
> >
> > 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!

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

[Josef Bacik]

On 8/19/20 8:42 PM, Neal Gompa wrote:
> On Wed, Aug 19, 2020 at 4:37 PM Josef Bacik <josef@toxicpanda.com> wrote:
>>
>> 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...)
> 

I'm not strongly tied to github here, we just already have something in place 
for it and are familiar with how it works.  The biggest thing for myself (and 
the rest of us I assume) is ease of integration.  I basically only want to use 
the web interface to check status, otherwise I want CLI tools to handle most of 
the paperwork shuffling.  Does pagure have a CLI for doing this?  I saw some 
haskell thing that's like 5 years old, but nothing newer.  Even a basic JSON 
interface would be ok, I have a curl script that interacts with a JSON thing to 
text my phone for stuff, so I'm not opposed to rigging something like that up 
for our uses.  If Pagure can do exactly the same thing then I don't see a reason 
not to use that instead.  Thanks,

Josef

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

[Neal Gompa]

On Thu, Aug 20, 2020 at 9:27 AM Josef Bacik <josef@toxicpanda.com> wrote:
>
> On 8/19/20 8:42 PM, Neal Gompa wrote:
> > On Wed, Aug 19, 2020 at 4:37 PM Josef Bacik <josef@toxicpanda.com> wrote:
> >>
> >> 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...)
> >
>
> I'm not strongly tied to github here, we just already have something in place
> for it and are familiar with how it works.  The biggest thing for myself (and
> the rest of us I assume) is ease of integration.  I basically only want to use
> the web interface to check status, otherwise I want CLI tools to handle most of
> the paperwork shuffling.  Does pagure have a CLI for doing this?  I saw some
> haskell thing that's like 5 years old, but nothing newer.  Even a basic JSON
> interface would be ok, I have a curl script that interacts with a JSON thing to
> text my phone for stuff, so I'm not opposed to rigging something like that up
> for our uses.  If Pagure can do exactly the same thing then I don't see a reason
> not to use that instead.  Thanks,
>

There are a few CLI tools that exist:

pag: https://pagure.io/pag
pag-off: https://pagure.io/pag-off
pagure-cli: https://github.com/juhp/pagure-cli
cranc: https://pagure.io/cranc

There's a basic REST+JSON interface as well, the API documentation is
present on the /api endpoint of any pagure instance, like so:
http://pagure.io/api

I've written crappy curl+jq+shell things for interfacing with pagure
and that works perfectly fine. But there are a few wrapper libraries
if you want to use those:

Python: https://pagure.io/libpagure
Rust: https://pagure.io/ironthree/pagure-rs
Go: https://pagure.io/gopagure





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

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

[Neal Gompa]

On Thu, Aug 20, 2020 at 11:31 AM Neal Gompa <ngompa13@gmail.com> wrote:
>
>
> There's a basic REST+JSON interface as well, the API documentation is
> present on the /api endpoint of any pagure instance, like so:
> http://pagure.io/api
>

I should clarify here that "basic" means simple, not incomplete. Most
(if not all) actions in the UI are possible through the API.


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