Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg?

["Leif Lindholm" <leif@nuviainc.com>]

On Fri, May 15, 2020 at 14:51:28 +0200, Laszlo Ersek wrote:
> On 05/15/20 11:47, Ard Biesheuvel wrote:
> > On 5/15/20 11:42 AM, Laszlo Ersek wrote:
> >> On 05/14/20 18:20, Rebecca Cran wrote:
> >>>
> >>>> On May 14, 2020, at 4:24 AM, Laszlo Ersek <lersek@redhat.com> wrote:
> >>>>
> >>>> - The community not having any human resources permanently dedicated to
> >>>> bhyve regressions (testing, review, and post factum fixing) is fine, as
> >>>> long as the bhyve stakeholders can live with a matching frequency of
> >>>> regressions.
> >>>
> >>> Yes, I believe that would be acceptable.
> >>> Has there been a decision on the directory structure yet, or is that
> >>> likely to be something that will need resolved at the next Stewards
> >>> Meeting?
> >>
> >> Based on the discussion thus far, I'd suggest
> >> "OvmfPkg/SecondClass/Bhyve". If you have the time, just go ahead and
> >> submit the series like that, and wait for review.
> >>
> >> If you'd first like to be sure that everyone's OK with this pathname,
> >> then please wait for more feedback in this thread.
> >>
> > 
> > Please no. SecondClass/ implies some kind of hall of shame, which is not
> > a fair characterization.
> 
> OK. I didn't mean to put bhyve in a "pillory" (I agree it would be
> unfair), I just couldn't find better words for reflecting the separation
> you asked for.
> 
> > I think it would be better to simply host this code under OvmfPkg/Bhyve,
> 
> OK!
> 
> > and put some annotation in Maintainers.txt to document that regressions
> > that only affect Bhyve are not treated with the same level of urgency as
> > ones that affect OVMF for QEMU.
> 
> How about "S: Odd Fixes"? From:
> 
>   S: Status, one of the following:
>      Supported:  Someone is actually paid to look after this.
>      Maintained: Someone actually looks after it.
>      Odd Fixes:  It has a maintainer but they don't have time to do
>                  much other than throw the odd patch in. See below.
>      Orphan:     No current maintainer [but maybe you could take the
>                  role as you write your new code].
>      Obsolete:   Old code. Something tagged obsolete generally means
>                  it has been replaced by a better system and you
>                  should be using that.

That looks like exactly what it's for.

It *will* (since f355b986068a) mean GetMaintainer.py will print a
warning. If that's an issue, we could discuss changing the level at
which a warning is generated.

/
    Leif