| Message ID | 20210307113403.11028-1-thuth@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | MAINTAINERS: Merge the Gitlab-CI section into the generic CI section | expand |
Thomas Huth <thuth@redhat.com> writes: > The status of the gitlab-CI files is currently somewhat confusing, and > it is often not quite clear whether a patch should go via my tree or > via the testing tree of Alex. That situation has grown historically... > Initially, I was the only one using the gitlab-CI, just for my private > repository there. But in the course of time, the gitlab-CI switched to > use the containers from tests/docker/ (which is not part of the gitlab-CI > section in the MAINTAINERS file), and QEMU now even switched to gitlab.com > completely for the repository and will soon use it as its gating CI, too. > So it makes way more sense if the gitlab-ci.yml files belong to the people > who are owning the qemu-project on gitlab.com and take care of the gitlab > CI there. Thus let's merge the gitlab-ci section into the common "test and > build automation" section, I have no problem with this, might as well keep it all together. > and change the status of myself to a "reviewer" > there instead. Can we not have multiple maintainers? Considering how important keeping the testing green should be wouldn't it help to keep the bus factor lower (not to mention holidays/breaks and just plain busy with other things periods). It shouldn't be to hard to track as long as we mention when we queue things to our trees? > While we're at it, I'm also removing the line with Fam there for now, > since he was hardly active during the last years in this area anymore. > If he ever gets more time for this part again in the future, we surely > can add the line back again. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > MAINTAINERS | 19 ++++++------------- > 1 file changed, 6 insertions(+), 13 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 26c9454823..e9cd29ed0b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3262,17 +3262,21 @@ F: include/hw/remote/iohub.h > > Build and test automation > ------------------------- > -Build and test automation > +Build and test automation, Linux Continuous Integration > M: Alex Bennée <alex.bennee@linaro.org> > -M: Fam Zheng <fam@euphon.net> > R: Philippe Mathieu-Daudé <philmd@redhat.com> > +R: Thomas Huth <thuth@redhat.com> > +R: Wainer dos Santos Moschetta <wainersm@redhat.com> > S: Maintained > F: .github/lockdown.yml > +F: .gitlab-ci.yml > +F: .gitlab-ci.d/ > F: .travis.yml > F: scripts/ci/ > F: tests/docker/ > F: tests/vm/ > F: scripts/archive-source.sh > +W: https://gitlab.com/qemu-project/qemu/pipelines > W: https://travis-ci.org/qemu/qemu > W: http://patchew.org/QEMU/ > > @@ -3289,17 +3293,6 @@ S: Maintained > F: .cirrus.yml > W: https://cirrus-ci.com/github/qemu/qemu > > -GitLab Continuous Integration > -M: Thomas Huth <thuth@redhat.com> > -M: Philippe Mathieu-Daudé <philmd@redhat.com> > -M: Alex Bennée <alex.bennee@linaro.org> > -R: Wainer dos Santos Moschetta <wainersm@redhat.com> > -S: Maintained > -F: .gitlab-ci.yml > -F: .gitlab-ci.d/crossbuilds.yml > -F: .gitlab-ci.d/*py > -F: scripts/ci/gitlab-pipeline-status > - > Guest Test Compilation Support > M: Alex Bennée <alex.bennee@linaro.org> > R: Philippe Mathieu-Daudé <f4bug@amsat.org>
On 08/03/2021 12.57, Alex Bennée wrote: > > Thomas Huth <thuth@redhat.com> writes: > >> The status of the gitlab-CI files is currently somewhat confusing, and >> it is often not quite clear whether a patch should go via my tree or >> via the testing tree of Alex. That situation has grown historically... >> Initially, I was the only one using the gitlab-CI, just for my private >> repository there. But in the course of time, the gitlab-CI switched to >> use the containers from tests/docker/ (which is not part of the gitlab-CI >> section in the MAINTAINERS file), and QEMU now even switched to gitlab.com >> completely for the repository and will soon use it as its gating CI, too. >> So it makes way more sense if the gitlab-ci.yml files belong to the people >> who are owning the qemu-project on gitlab.com and take care of the gitlab >> CI there. Thus let's merge the gitlab-ci section into the common "test and >> build automation" section, > > I have no problem with this, might as well keep it all together. > >> and change the status of myself to a "reviewer" >> there instead. > > Can we not have multiple maintainers? Considering how important keeping > the testing green should be wouldn't it help to keep the bus factor > lower (not to mention holidays/breaks and just plain busy with other > things periods). It shouldn't be to hard to track as long as we mention > when we queue things to our trees? Sure, it certainly makes sense to have multiple maintainers, but I think in this section, it might be better to also have someone who's also a maintainer of the qemu-project at gitlab (in case there's something to fix/setup with a custom runner for example, and to avoid wrong expectations)? Maybe Peter finally wants to join here to get finally away from his exclusive merge tests? Thomas
Hi Alex, On 3/8/21 12:57 PM, Alex Bennée wrote: > > Thomas Huth <thuth@redhat.com> writes: > >> The status of the gitlab-CI files is currently somewhat confusing, and >> it is often not quite clear whether a patch should go via my tree or >> via the testing tree of Alex. That situation has grown historically... >> Initially, I was the only one using the gitlab-CI, just for my private >> repository there. But in the course of time, the gitlab-CI switched to >> use the containers from tests/docker/ (which is not part of the gitlab-CI >> section in the MAINTAINERS file), and QEMU now even switched to gitlab.com >> completely for the repository and will soon use it as its gating CI, too. >> So it makes way more sense if the gitlab-ci.yml files belong to the people >> who are owning the qemu-project on gitlab.com and take care of the gitlab >> CI there. Thus let's merge the gitlab-ci section into the common "test and >> build automation" section, > > I have no problem with this, might as well keep it all together. > >> and change the status of myself to a "reviewer" >> there instead. > > Can we not have multiple maintainers? Considering how important keeping > the testing green should be wouldn't it help to keep the bus factor > lower (not to mention holidays/breaks and just plain busy with other > things periods). It shouldn't be to hard to track as long as we mention > when we queue things to our trees? I'm OK to be listed as backup maintainer as I do have a genuine interest in CI/testing. It will be in my scarcer personal time although, so better if another maintainers with more resources could pop up along instead. >> While we're at it, I'm also removing the line with Fam there for now, >> since he was hardly active during the last years in this area anymore. >> If he ever gets more time for this part again in the future, we surely >> can add the line back again. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> >> --- >> MAINTAINERS | 19 ++++++------------- >> 1 file changed, 6 insertions(+), 13 deletions(-)
On 08/03/2021 14.34, Philippe Mathieu-Daudé wrote: > Hi Alex, > > On 3/8/21 12:57 PM, Alex Bennée wrote: >> >> Thomas Huth <thuth@redhat.com> writes: >> >>> The status of the gitlab-CI files is currently somewhat confusing, and >>> it is often not quite clear whether a patch should go via my tree or >>> via the testing tree of Alex. That situation has grown historically... >>> Initially, I was the only one using the gitlab-CI, just for my private >>> repository there. But in the course of time, the gitlab-CI switched to >>> use the containers from tests/docker/ (which is not part of the gitlab-CI >>> section in the MAINTAINERS file), and QEMU now even switched to gitlab.com >>> completely for the repository and will soon use it as its gating CI, too. >>> So it makes way more sense if the gitlab-ci.yml files belong to the people >>> who are owning the qemu-project on gitlab.com and take care of the gitlab >>> CI there. Thus let's merge the gitlab-ci section into the common "test and >>> build automation" section, >> >> I have no problem with this, might as well keep it all together. >> >>> and change the status of myself to a "reviewer" >>> there instead. >> >> Can we not have multiple maintainers? Considering how important keeping >> the testing green should be wouldn't it help to keep the bus factor >> lower (not to mention holidays/breaks and just plain busy with other >> things periods). It shouldn't be to hard to track as long as we mention >> when we queue things to our trees? > > I'm OK to be listed as backup maintainer as I do have a genuine > interest in CI/testing. It will be in my scarcer personal time > although, so better if another maintainers with more resources > could pop up along instead. Well, I guess if Philippe is around for helping at least with the maintainer stuff in the qemu-project on gitlab.com, I can also continue as a backup for picking up the related CI patches if you like (unless someone else wants to volunteer)... I'll send a v2 for this patch accordingly... Thomas
On Mon, 8 Mar 2021 at 12:33, Thomas Huth <thuth@redhat.com> wrote: > Sure, it certainly makes sense to have multiple maintainers, but I think in > this section, it might be better to also have someone who's also a > maintainer of the qemu-project at gitlab (in case there's something to > fix/setup with a custom runner for example, and to avoid wrong > expectations)? Maybe Peter finally wants to join here to get finally away > from his exclusive merge tests? The idea with moving away from my local merge scripts is specifically that I *do not* want to be maintaining CI related stuff :-) I'm happy that we give the person who does want to be doing that work the necessary rights on the qemu-project at gitlab. thanks -- PMM
diff --git a/MAINTAINERS b/MAINTAINERS index 26c9454823..e9cd29ed0b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3262,17 +3262,21 @@ F: include/hw/remote/iohub.h Build and test automation ------------------------- -Build and test automation +Build and test automation, Linux Continuous Integration M: Alex Bennée <alex.bennee@linaro.org> -M: Fam Zheng <fam@euphon.net> R: Philippe Mathieu-Daudé <philmd@redhat.com> +R: Thomas Huth <thuth@redhat.com> +R: Wainer dos Santos Moschetta <wainersm@redhat.com> S: Maintained F: .github/lockdown.yml +F: .gitlab-ci.yml +F: .gitlab-ci.d/ F: .travis.yml F: scripts/ci/ F: tests/docker/ F: tests/vm/ F: scripts/archive-source.sh +W: https://gitlab.com/qemu-project/qemu/pipelines W: https://travis-ci.org/qemu/qemu W: http://patchew.org/QEMU/ @@ -3289,17 +3293,6 @@ S: Maintained F: .cirrus.yml W: https://cirrus-ci.com/github/qemu/qemu -GitLab Continuous Integration -M: Thomas Huth <thuth@redhat.com> -M: Philippe Mathieu-Daudé <philmd@redhat.com> -M: Alex Bennée <alex.bennee@linaro.org> -R: Wainer dos Santos Moschetta <wainersm@redhat.com> -S: Maintained -F: .gitlab-ci.yml -F: .gitlab-ci.d/crossbuilds.yml -F: .gitlab-ci.d/*py -F: scripts/ci/gitlab-pipeline-status - Guest Test Compilation Support M: Alex Bennée <alex.bennee@linaro.org> R: Philippe Mathieu-Daudé <f4bug@amsat.org>
The status of the gitlab-CI files is currently somewhat confusing, and it is often not quite clear whether a patch should go via my tree or via the testing tree of Alex. That situation has grown historically... Initially, I was the only one using the gitlab-CI, just for my private repository there. But in the course of time, the gitlab-CI switched to use the containers from tests/docker/ (which is not part of the gitlab-CI section in the MAINTAINERS file), and QEMU now even switched to gitlab.com completely for the repository and will soon use it as its gating CI, too. So it makes way more sense if the gitlab-ci.yml files belong to the people who are owning the qemu-project on gitlab.com and take care of the gitlab CI there. Thus let's merge the gitlab-ci section into the common "test and build automation" section, and change the status of myself to a "reviewer" there instead. While we're at it, I'm also removing the line with Fam there for now, since he was hardly active during the last years in this area anymore. If he ever gets more time for this part again in the future, we surely can add the line back again. Signed-off-by: Thomas Huth <thuth@redhat.com> --- MAINTAINERS | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-)