On Mon, Mar 8, 2021 at 6:14 AM Philippe Mathieu-Daudé <phi...@redhat.com>
wrote:

> On 3/8/21 1:14 PM, Daniel P. Berrangé wrote:
> > On Mon, Mar 08, 2021 at 12:55:10PM +0100, Thomas Huth wrote:
> >> On 08/03/2021 12.16, Philippe Mathieu-Daudé wrote:
> >>> Hi Peter,
> >>>
> >>> +Markus/Paolo/Laurent/Richard
> >>>
> >>> On 3/8/21 11:24 AM, Peter Maydell wrote:
> >>>> On Mon, 8 Mar 2021 at 10:09, Thomas Huth <th...@redhat.com> wrote:
> >>>>>
> >>>>> On 07/03/2021 16.56, Warner Losh wrote:
> >>>>>> The FreeBSD project has a number of enhancements to bsd-user. Add
> myself
> >>>>>> as maintainer and Kyle Evans as a reviewer. Also add our github
> repo.
> >>>>>>
> >>>>>> Signed-off-by: Warner Losh <i...@bsdimp.com>
> >>>>>> Signed-off-by: Kyle Evans <kev...@freebsd.org>
> >>>>>> Reviewed-by: Thomas Huth <th...@redhat.com>
> >>>>>> ---
> >>>>>>    MAINTAINERS | 5 ++++-
> >>>>>>    1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>>>>> index 26c9454823..ec0e935038 100644
> >>>>>> --- a/MAINTAINERS
> >>>>>> +++ b/MAINTAINERS
> >>>>>> @@ -2896,9 +2896,12 @@ F: thunk.c
> >>>>>>    F: accel/tcg/user-exec*.c
> >>>>>>
> >>>>>>    BSD user
> >>>>>> -S: Orphan
> >>>>>> +M: Warner Losh <i...@bsdimp.com>
> >>>>>> +R: Kyle Evans <kev...@freebsd.org>
> >>>>>> +S: Maintained
> >>>>>>    F: bsd-user/
> >>>>>>    F: default-configs/targets/*-bsd-user.mak
> >>>>>> +T: git https://github.com/qemu-bsd-user/qemu-bsd-user
> bsd-user-rebase-3.1
> >>>>>
> >>>>> BSD is not really my home turf, but since nobody else picked this up
> and I
> >>>>> plan to send a pull request for a bunch of patches anyway this week,
> I can
> >>>>> also put it into my queue.
> >>>>
> >>>> Fine with me. (The v1 was in my to-review queue, but I'm currently
> >>>> running somewhat behind on processing patches.)
> >>>
> >>> This is a patch for mainstream QEMU, I'm having hard time
> >>> understanding the point of it. This is some official way
> >>> to say that BSD-user is not maintained in mainstream but
> >>> has to be used in the referred fork which is way different
> >>> that mainstream...
> >>>
> >>> I'd rather wait for more mainstream contributions from Warner
> >>> and Kyle, or blow the current orphan/dead code and import
> >>> bsd-user-rebase-3.1 adding the maintainer entries along, but
> >>> certainly not mark this dead code as maintained.
> >>>
> >>> Please convince me why I'm wrong, because I'd prefer NAck this
> >>> patch...
> >>
> >> The idea has been discussed here:
> >>
> >> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01399.html
> >>
> >> So this is not about declaring that bsd-user is maintained in a
> different
> >> repository, but about giving Warner et al. a chance to finally upstream
> >> their work.
> >
> > Yep, I think this change in MAINTAINERS file is primarily about
> signalling
> > intent for future
>

 Yes. Just so. We have the older fork that we're trying to port forward. If
people have changes as we do that, it sure would be nice to have them go
through us rather than create more conflict with the main tree. I don't
need to have a new set of conflicts with main because someone thought that
it would be a good idea to move the space before or after the '(' or after
in a bunch of files. It's just extra work if I have to do it as part of the
merging. Better that goes into the top of our queue so it's managed and
easy and a click on github than another half hour I have to spend sorting
that out when I'd rather be sorting out the substantial change that go on
upstream in other areas that legitimately do make things much better.

We talked about all this in the above thread, I thought, and I thought it
was all settled, so I was rather surprised to wake up to this thread this
morning.


> > Marking the subsystem as maintained isn't saying the current code is
> great,
> > just that there is someone committed to improving it hereafter.
>
> OK, thank Thomas / Daniel for explaining and referring to the "BSD-user
> plans" (which I didn't notice earlier).
>
> Warner, what about mentioning your plans here in this patch?
>

Where is there room in the MAINTAINERS file for that? How would you like me
to do that?


> Resumed ideally, else a simple link to the thread.
>

I'm not sure what you are asking here.


> > If we want to warn people that the current impl isn't great, that's goes
> > back to the topic of having a way to classify QEMU features into quality
> > levels Tier 1/2/3.
>
> That indeed sounds good w.r.t. contributors / users expectations.
>
> I suppose 1=hw_accel/security, 2=tested, 3=rest?
>
> Not a single clue how to do that although.
>

Yup. Why invent something new just to make it harder for me to get things
into the tree? There's already the tiered maintainer stuff, and I'm trying
to get our stuff that turn the current bsd-user that's crap into something
that's quite solid.

The plans are to get our changes upstream so there's no daylight between
what we do and what's upstream, except for the newest system calls that are
being implemented just after they enter FreeBSD. We have a bunch of changes
that make bsd-user able to build tens of thousands of packages more or less
natively (the setup is a hybrid environment where the compilers are cross
compilers, but everything built is native and run in emulation).

I tried getting one big omnibus patch together, but qemu's head is moving
too fast, so those plans failed to ever reach the tip of the tree. In
discussions referenced in this thread, people suggested I submit changes to
the MAINTAINER stuff as a signal moving forward. I've submitted other
patches as well to get things going (those are already in). I plan on
submitting more, but wanted to get the simple stuff ironed out first.
QEMU's workflow is utterly alien to me, to be honest, but I wanted to be a
good citizen and learn on the basics before submitting things that were
harder to do and/or explain.

Anyway, I'm trying to learn the local customs here. I'm unsure what the
next step here is. Can someone explicitly tell me that? I thought all these
preliminaries were already sorted out.

Warner

Reply via email to