Move to github workflow?

[Mark Cave-Ayland]

Hi all,

Since the coreboot team moved the OpenBIOS project onto Github, there have been a 
number of steadily increasing pull requests and issues raised there and so I'm 
wondering if now is the time to start thinking about moving to a more Github-based 
workflow.

The nice thing about Github is that we can start to put together some CI to allow 
build testing of PRs and open potential review to people outside of the OpenBIOS 
mailing list. However there are a number of very knowledgeable people on this mailing 
list who have helped with the project over the years and I am really keen to maintain 
the benefit of their expertise.

On this basis I would like to propose the following changes:

1) Move to a merge request workflow and start accepting PRs from Github

2) Add the [e-mail] mailing list automatically to Github PRs
      and Issues so people on the mailing can take part in the discussions.
      Note: this is currently VERY low volume.

3) Implement a basic Github workflow using the QEMU project cross-compiler
      docker images to enable build testing and artifact generation without
      requiring a cross-compiler to be built manually. (I've already tried a few
      experiments and made some progress here).

Any further thoughts/ideas/suggestions?

ATB,

Mark.

[Philippe Mathieu-Daudé]

On Thu, Aug 19, 2021 at 11:02 AM Mark Cave-Ayland
 wrote:
> Hi all,
>
> Since the coreboot team moved the OpenBIOS project onto Github, there have been a
> number of steadily increasing pull requests and issues raised there and so I'm
> wondering if now is the time to start thinking about moving to a more Github-based
> workflow.

Why GitHub and not GitLab?
> The nice thing about Github is that we can start to put together some CI to allow
> build testing of PRs and open potential review to people outside of the OpenBIOS
> mailing list. However there are a number of very knowledgeable people on this mailing
> list who have helped with the project over the years and I am really keen to maintain
> the benefit of their expertise.

I'm pretty sure some 'bots' exist that can send PR patches via email
to the list.

Personally I find the Web-UI review process awkward (besides most of the time
I do review I'm offline), and hard to grep (instead of an email archive).

Also it makes it harder for blind developers to contribute, but I
think git forge
projects are trying to catch up there.

Anyway we all have to adapt, and I agree using git forges help to reach another
audience (as long as it doesn't kick out the current one).

CI is certainly a big win.
> On this basis I would like to propose the following changes:
>
> Move to a merge request workflow and start accepting PRs from Github
>
> Add the [e-mail] mailing list automatically to Github PRs
> and Issues so people on the mailing can take part in the discussions.
> Note: this is currently VERY low volume.
>
> Implement a basic Github workflow using the QEMU project cross-compiler
> docker images to enable build testing and artifact generation without
> requiring a cross-compiler to be built manually. (I've already tried a few
> experiments and made some progress here).
>
> Any further thoughts/ideas/suggestions?
>
> ATB,
>
> Mark.
> _______________________________________________
> OpenBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Stefan Reinauer]

On Thu, Aug 19, 2021 at 3:13 AM Philippe Mathieu-Daudé 
wrote:
> On Thu, Aug 19, 2021 at 11:02 AM Mark Cave-Ayland
>  wrote:
> > Hi all,
> >
> > Since the coreboot team moved the OpenBIOS project onto Github, there
>
> have been a
> > number of steadily increasing pull requests and issues raised there and
>
> so I'm
> > wondering if now is the time to start thinking about moving to a more
>
> Github-based
> > workflow.
>
> Why GitHub and not GitLab?

Good question. Because that is where the code already lives, so it is a
minimal change for everybody So if you want to suggest that to change, the
question might be:
Why GitLab and not GitHub?
> > The nice thing about Github is that we can start to put together some CI
>
> to allow
> > build testing of PRs and open potential review to people outside of the
>
> OpenBIOS
> > mailing list. However there are a number of very knowledgeable people on
>
> this mailing
> > list who have helped with the project over the years and I am really
>
> keen to maintain
> > the benefit of their expertise.
>
> I'm pretty sure some 'bots' exist that can send PR patches via email
> to the list.

Yes we can do this I'm pretty sure.
> Personally I find the Web-UI review process awkward (besides most of the
> time
> I do review I'm offline), and hard to grep (instead of an email archive).

Yes, particularly the github work flow is a bit cumbersome, at least if
you're not used to it initially.
On the positive side, you can always download pull requests to your git
tree to test and review locally.
> Also it makes it harder for blind developers to contribute, but I
> think git forge
> projects are trying to catch up there.

There is a github command line client that might help with this.
> Anyway we all have to adapt, and I agree using git forges help to reach
> another
> audience (as long as it doesn't kick out the current one).
>
> CI is certainly a big win.

Yes, this can really change our quality in the long run.
> > On this basis I would like to propose the following changes:
> > Move to a merge request workflow and start accepting PRs from
>
> Github
> > Add the [e-mail] mailing list automatically to
>
> Github PRs
> >   and Issues so people on the mailing can take part in the
>
> discussions.
> >   Note: this is currently VERY low volume.
> >
> > Implement a basic Github workflow using the QEMU project
>
> cross-compiler
> >   docker images to enable build testing and artifact generation
>
> without
> >   requiring a cross-compiler to be built manually. (I've already
>
> tried a few
> >   experiments and made some progress here).

This sounds great!
> > Any further thoughts/ideas/suggestions?

If we're making infrastructure changes, do we want to switch from MediaWiki
to a different solution for the web page?

(And we should do a release, the last release update on the web page was 8
years ago)

Stefan

[Patrick Georgi]

Am 19.08.2021 um 19:35 schrieb Stefan Reinauer:
> If we're making infrastructure changes, do we want to switch from 
> MediaWiki to a different solution for the web page?

Since we're talking github: github pages? According to 
https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github... 
they support custom hostnames.

That said, it's really an orthogonal effort: Code Review flow and CI can 
and should be improved independently from the website.
> (And we should do a release, the last release update on the web page was 
> 8 years ago)

Speaking from coreboot experience, there really should be a release: 
coreboot was generally considered dead after 2 years or so without one...

Patrick

[Philippe Mathieu-Daudé]

On Thu, Aug 19, 2021 at 7:35 PM Stefan Reinauer
 wrote:
> On Thu, Aug 19, 2021 at 3:13 AM Philippe Mathieu-Daudé  wrote:
> > On Thu, Aug 19, 2021 at 11:02 AM Mark Cave-Ayland
> >  wrote:
> > > Hi all,
> > >
> > > Since the coreboot team moved the OpenBIOS project onto Github, there have been a
> > > number of steadily increasing pull requests and issues raised there and so I'm
> > > wondering if now is the time to start thinking about moving to a more Github-based
> > > workflow.
> >
> > Why GitHub and not GitLab?
>
> Good question. Because that is where the code already lives, so it is a minimal change for everybody So if you want to suggest that to change, the question might be:
> Why GitLab and not GitHub?

Because you are not tied to a service provider by being able to export
the project metadata?

Otherwise there is no big difference in my daily experience. What
matters is what's best
adapted to the OpenBIOS community, and where new contributors are likely to be
(probably in both anyway).

("where the code already lives" is easy to solve, simply configure
github as gitlab mirror).

[Mark Cave-Ayland]

On 19/08/2021 18:35, Stefan Reinauer wrote:
> On Thu, Aug 19, 2021 at 3:13 AM Philippe Mathieu-Daudé <[e-mail] 
> > wrote:
> On Thu, Aug 19, 2021 at 11:02 AM Mark Cave-Ayland
> <[e-mail] <mailto:[e-mail]>> wrote:
>  >
>  > Hi all,
>  >
>  > Since the coreboot team moved the OpenBIOS project onto Github, there have been a
>  > number of steadily increasing pull requests and issues raised there and so I'm
>  > wondering if now is the time to start thinking about moving to a more Github-based
>  > workflow.
>
> Why GitHub and not GitLab?
>
> Good question. Because that is where the code already lives, so it is a 
> minimal change for everybody So if you want to suggest that to change, the question 
> might be:
> Why GitLab and not GitHub?

QEMU have decided on GitLab so there may be a slight preference there, but otherwise 
I don't believe there is too much difference between both services?
>  > The nice thing about Github is that we can start to put together some CI to allow
>  > build testing of PRs and open potential review to people outside of the OpenBIOS
>  > mailing list. However there are a number of very knowledgeable people on this
> mailing
>  > list who have helped with the project over the years and I am really keen to
> maintain
>  > the benefit of their expertise.
>
> I'm pretty sure some 'bots' exist that can send PR patches via email
> to the list.
>
>
> Yes we can do this I'm pretty sure.
> Personally I find the Web-UI review process awkward (besides most of the time
> I do review I'm offline), and hard to grep (instead of an email archive).
>
>
> Yes, particularly the github work flow is a bit cumbersome, at least if you're not 
> used to it initially.
> On the positive side, you can always download pull requests to your git tree to test 
> and review locally.

I tend to find that this is based upon experience: for new contributors it is much 
easier to open a PR on Github and manage the review/merge there, whereas for higher 
volume patch management (and also people used to kernel workflow) mailing lists tend 
to work much better in my experience.
> Also it makes it harder for blind developers to contribute, but I
> think git forge
> projects are trying to catch up there.
>
>
> There is a github command line client that might help with this.
> Anyway we all have to adapt, and I agree using git forges help to reach another
> audience (as long as it doesn't kick out the current one).
>
> CI is certainly a big win.
>
>
> Yes, this can really change our quality in the long run.
>  > On this basis I would like to propose the following changes:
>  >
>  >    1) Move to a merge request workflow and start accepting PRs from Github
>  >
>  >    2) Add the [e-mail] <mailto:[e-mail]> mailing
> list automatically to Github PRs
>  >       and Issues so people on the mailing can take part in the discussions.
>  >       Note: this is currently VERY low volume.
>  >
>  >    3) Implement a basic Github workflow using the QEMU project cross-compiler
>  >       docker images to enable build testing and artifact generation without
>  >       requiring a cross-compiler to be built manually. (I've already tried a few
>  >       experiments and made some progress here).
>
>
> This sounds great!

I haven't used Github workflows before but it was a reasonably straightforward 
experience to get it up and running thanks to the QEMU docker images. See 
https://github.com/mcayland/openbios/commit/a027ba769f9cd53c75ac96d60b6839f8... 
for building x86, amd64, sparc32, sparc64 and ppc images and storing the artifacts.

Merging the workflow should cause the build to run when cloned repositories push to 
branches so we can at least get some basic checks in place for contributors who raise 
PRs.
>  > Any further thoughts/ideas/suggestions?
>
>
> If we're making infrastructure changes, do we want to switch from MediaWiki to a 
> different solution for the web page?

MediaWiki is okay, although it is a slightly higher bar to make changes given that 
wiki accounts need to be set up separately.
> (And we should do a release, the last release update on the web page was 8 years ago)

Yeah I guess that's my fault. Blue Swirl used to do the release management and I was 
never particularly confident to do that with SVN, although git is much easier. 
Certainly there have been many, many fixes and improvements since the last release.

ATB,

Mark.