| Message ID | 1466432365-11908-1-git-send-email-armbru@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 20 June 2016 at 10:19, Markus Armbruster <armbru@redhat.com> wrote: > > As per Paolo's recommendation, downgrade status of "BSD user" from > Maintained to Orphan since the FreeBSD guys effectively forked it, and > "SPARC target" from Maintained to Odd Fixes, since we still have the > overall TCG maintainer looking after it. Note that we are still very interested in having the BSD user refactoring and improvements upstream, and are not interested in indefinitely carrying around a fork. We do need to figure out how to effectively restart the effort to upstream the work. The bsd-user work is stable and usable. We use it to cross-build more than 20,000 packages of third-party software in the FreeBSD ports collection.
On 29/06/2016 15:24, Ed Maste wrote: > On 20 June 2016 at 10:19, Markus Armbruster <armbru@redhat.com> wrote: >> >> As per Paolo's recommendation, downgrade status of "BSD user" from >> Maintained to Orphan since the FreeBSD guys effectively forked it, and >> "SPARC target" from Maintained to Odd Fixes, since we still have the >> overall TCG maintainer looking after it. > > Note that we are still very interested in having the BSD user > refactoring and improvements upstream, and are not interested in > indefinitely carrying around a fork. We do need to figure out how to > effectively restart the effort to upstream the work. > > The bsd-user work is stable and usable. We use it to cross-build more > than 20,000 packages of third-party software in the FreeBSD ports > collection. Honestly I'm wondering if a huge code drop could be the right solution here. It's not how we usually do things, but rules exist to be broken... Paolo
On 29 June 2016 at 14:32, Paolo Bonzini <pbonzini@redhat.com> wrote: > Honestly I'm wondering if a huge code drop could be the right solution > here. It's not how we usually do things, but rules exist to be broken... I can't say I'm really enthusiastic about doing that. thanks -- PMM
On 29/06/2016 17:10, Peter Maydell wrote: >> Honestly I'm wondering if a huge code drop could be the right solution >> here. It's not how we usually do things, but rules exist to be broken... > > I can't say I'm really enthusiastic about doing that. Neither am I. On the other hand, look at the code that we have---nobody is using it, nobody is fixing it. Last year it stayed broken for a month between commit ea3e98474 and commit cb48f67ad. It cannot really be worse than the FreeBSD fork. Of course the bits outside bsd-user/ would need proper review. Paolo
On 29 June 2016 at 16:22, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 29/06/2016 17:10, Peter Maydell wrote: >>> Honestly I'm wondering if a huge code drop could be the right solution >>> here. It's not how we usually do things, but rules exist to be broken... >> >> I can't say I'm really enthusiastic about doing that. > > Neither am I. On the other hand, look at the code that we have---nobody > is using it, nobody is fixing it. Last year it stayed broken for a > month between commit ea3e98474 and commit cb48f67ad. It cannot really > be worse than the FreeBSD fork. Of course the bits outside bsd-user/ > would need proper review. I think from an upstream-maintainer viewpoint the question is whether a code drop would be just a code drop, or whether it gets us to a position where we have an active upstream maintainer for the bsd-user code. I think the latter would be a win for everybody. thanks -- PMM
Paolo Bonzini <pbonzini@redhat.com> writes: > On 29/06/2016 17:10, Peter Maydell wrote: >>> Honestly I'm wondering if a huge code drop could be the right solution >>> here. It's not how we usually do things, but rules exist to be broken... >> >> I can't say I'm really enthusiastic about doing that. > > Neither am I. On the other hand, look at the code that we have---nobody > is using it, nobody is fixing it. Last year it stayed broken for a > month between commit ea3e98474 and commit cb48f67ad. It cannot really > be worse than the FreeBSD fork. Of course the bits outside bsd-user/ > would need proper review. Do the BSD folk have any CI? Could they track our master as well? > > Paolo -- Alex Bennée
On 29 June 2016 at 14:03, Peter Maydell <peter.maydell@linaro.org> wrote: > > I think from an upstream-maintainer viewpoint the question is > whether a code drop would be just a code drop, or whether > it gets us to a position where we have an active upstream > maintainer for the bsd-user code. I think the latter would > be a win for everybody. I can't speak for Sean and he's AFK for a week or two, but he's been performing this function for the fork for some time -- updating it for changes in the rest of QEMU, etc. I think we've been stuck on upstreaming it because it is somewhat awkward to refactor and is a reasonable amount of effort, and we've lacked a bsd-user maintainer to review or approve the patches anyhow. I agree with a large code drop being undesirable. Given current expectations (with bsd-user unmaintained) I hope we can make another push to refactor and upstream the changes. We should be able to put in some effort to present the patches in a sensible and logical order and I'm willing to help with that. Perhaps we'll need a little leeway on the parts specific to bsd-user, but I'm really hopeful we can make this happen. I also hope some folks from NetBSD, OpenBSD, DragonflyBSD and others will help test the patch sets.
On 29 June 2016 at 16:35, Ed Maste <emaste@freebsd.org> wrote: > > I agree with a large code drop being undesirable. Here's a little more information for reference. Sean's qemu-bsd-user branch is here: https://github.com/seanbruno/qemu-bsd-user The last upstream merge was from commit d6550e9e about a month ago. Diffstat reports: 243 files changed, 34213 insertions(+), 2898 deletions(-) 225 of those files are in bsd-user or are bsd-user.mak files in default-configs. The remaining changes outside of bsd-user are: Makefile.target | 2 configure | 99 + hw/audio/sb16.c | 6 hw/dma/i8257.c | 8 hw/intc/i8259.c | 1 hw/net/e1000.c | 2 include/qemu/atomic.h | 4 include/qemu/fprintf-fn.h | 10 net/clients.h | 5 net/hub.c | 1 net/net.c | 224 ++ net/tap-bsd.c | 1 net/tap.c | 8 qapi-schema.json | 5 qemu-char.c | 7 slirp/slirp_config.h | 18 ui/x_keymap.c | 6 They seem to be mostly unrelated to bsd-user itself but are patches taken from the FreeBSD ports tree - e.g. adding "-net pcap" https://svnweb.freebsd.org/ports/head/emulators/qemu-devel/files/pcap-patch-net_net.c?revision=416075&view=markup
On 20 June 2016 at 15:19, Markus Armbruster <armbru@redhat.com> wrote: > Blue hasn't been active in the QEMU project for a long time. Drop his > last MAINTAINERS entries. > > As per Paolo's recommendation, downgrade status of "BSD user" from > Maintained to Orphan since the FreeBSD guys effectively forked it, and > "SPARC target" from Maintained to Odd Fixes, since we still have the > overall TCG maintainer looking after it. > > I'm leaving Checkpatch's status at Odd Fixes. Calling it Maintained > wouldn't be wrong, but I'm not comfortable upgrading it while nobody > is willing to have his name nailed to the thing. > > Cc: Paolo Bonzini <pbonzini@redhat.com> > Signed-off-by: Markus Armbruster <armbru@redhat.com> Applied to master, thanks. When we resolve the bsd-user situation we can update MAINTAINERS with its new status/maintainer. -- PMM
On 07/05/16 08:18, Ed Maste wrote: > On 29 June 2016 at 16:35, Ed Maste <emaste@freebsd.org> wrote: >> On 29 June 2016 at 14:03, Peter Maydell <peter.maydell@linaro.org> wrote: >>> >>> I think from an upstream-maintainer viewpoint the question is >>> whether a code drop would be just a code drop, or whether >>> it gets us to a position where we have an active upstream >>> maintainer for the bsd-user code. I think the latter would >>> be a win for everybody. >> >> I can't speak for Sean and he's AFK for a week or two, but he's been >> performing this function for the fork for some time -- updating it for >> changes in the rest of QEMU, etc. I think we've been stuck on >> upstreaming it because it is somewhat awkward to refactor and is a >> reasonable amount of effort, and we've lacked a bsd-user maintainer to >> review or approve the patches anyhow. >> >> I agree with a large code drop being undesirable. Given current >> expectations (with bsd-user unmaintained) I hope we can make another >> push to refactor and upstream the changes. We should be able to put in >> some effort to present the patches in a sensible and logical order and >> I'm willing to help with that. Perhaps we'll need a little leeway on >> the parts specific to bsd-user, but I'm really hopeful we can make >> this happen. >> >> I also hope some folks from NetBSD, OpenBSD, DragonflyBSD and others >> will help test the patch sets. I freely submit myself as the "weak link" here. I've been updating to QEMU master monthly in order to track and keep the patchset alive for cross building FreeBSD ports and allow folks to do cross-development. I suspect, with the exception of two recent patches submitted to the list, most, if not all of the changes outside of bsd-user are due to my ignorance of branch maintenance *or* are patches that have been languishing in the FreeBSD's pot of QEMU. To the question of CI for our version of QEMU, in a way, yes. It is used daily/weekly to build FreeBSD ports for mips, mips64 and armv6. It is being tested for armv5 and arm64/aarch64, but this is not a daily occurrence. I can branch master and setup a second "code bomb" that doesn't touch outside of bsd-user if that is something we want to move forward with. sean
diff --git a/MAINTAINERS b/MAINTAINERS index dbc7a18..d8475da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1261,7 +1261,6 @@ F: docs/tracing.txt T: git git://github.com/stefanha/qemu.git tracing Checkpatch -M: Blue Swirl <blauwirbel@gmail.com> S: Odd Fixes F: scripts/checkpatch.pl @@ -1334,8 +1333,7 @@ F: thunk.c F: user-exec.c BSD user -M: Blue Swirl <blauwirbel@gmail.com> -S: Maintained +S: Orphan F: bsd-user/ Linux user @@ -1398,8 +1396,7 @@ F: tcg/s390/ F: disas/s390.c SPARC target -M: Blue Swirl <blauwirbel@gmail.com> -S: Maintained +S: Odd Fixes F: tcg/sparc/ F: disas/sparc.c
Blue hasn't been active in the QEMU project for a long time. Drop his last MAINTAINERS entries. As per Paolo's recommendation, downgrade status of "BSD user" from Maintained to Orphan since the FreeBSD guys effectively forked it, and "SPARC target" from Maintained to Odd Fixes, since we still have the overall TCG maintainer looking after it. I'm leaving Checkpatch's status at Odd Fixes. Calling it Maintained wouldn't be wrong, but I'm not comfortable upgrading it while nobody is willing to have his name nailed to the thing. Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> --- MAINTAINERS | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)