Re: Feb 19 meeting actions, discussion, notes, and recording

On 3/1/25 1:57 AM, Chris Moerz wrote:
> On Fri, 28 Feb 2025, Michael Dexter wrote:
>> On 2/28/25 11:16 AM, Greg Wallace wrote:
>>> I'm not sure I totally follow, but I *think* you're suggesting that the
>>> bhyve manageability workstream from EWG be absorbed into the production
>>> users call.
>>
>> That is an attractive approach of many possible ones. Chris M has de facto
>> played this role regardless of the exact affiliation.
>>
>> Chris, perhaps you can speak from the EWR perspective?
>>
> 
> TLDR: yup. Let's do it.
> 
> ...
> 
> Admittedly, lately I have failed to put the necessary presence and energy
> into the bhyve manageability work stream, which would be required to move
> this forward consistently. I agree with Greg, that this is as much about
> resources (whether people or money makes no difference in my mind) as it
> is about focusing activities through a forum like regular calls or a
> mailing list.
> 
> Michael, in my opinion you have done more for bhyve (and jails, and ZFS,
> and so much more) than I could ever hope to achieve. A brief review of all
> recordings of the bhyve calls and hours of conversations about state
> management and various approaches to bhyve manageability will easily prove
> that your weekly calls are already the go-to-place for in-depth knowledge
> about bhyve and bhyve manageability.
> 
> The EWG calls with their monthly schedule vs the weekly bhyve
> calls condense that conversation around the state of things, summarizing
> ongoing activities and tracking progress and thus servce a slightly
> different purpose - as Greg pointed out.
> 
> The topic of "where/how to track/manage what?" is very much becoming more
> important to clarify. We now have an Enterprise Working Group, weekly
> bhyve calls, the Laptop and Desktop Working Group; then we've established
> a OCI testing group derived from that and we're lately also looking at the
> formation of a UX testing group. We'll need some kind of governance to
> manage with overlaps to avoid conflict and double work or rework.
> 
> Greg recently pointed this out in one of the Enterprise Working Group
> calls and we were already planning to draft some suggestions for how to
> address this. It's on me that we didn't manage to meet and discuss this
> yet - I'm still committed however. Maybe it makes sense to include you in
> the conversation, Michael?
> 
> Proof in point: one item on the Laptop and Desktop Workgroup agenda is
> improving virt-manager use with bhyve. Obviously, that connects to both
> your calls. Regardless of how/where it get's done - we all benefit. We
> simply should avoid working on it in parallel in multiple places.
> 
> You also independently raised the question, whether virt-manager wouldn't
> be a good path forward for bhyve manageability, Michael. Clearly we all
> see the writing on the wall.
> 
> I'd like to suggest we (Michael, Greg, Alice, me, anyone else?) figure out
> a draft for dealing with overlaps and also how to address the "elephant in
> the room" that occurs now and then: when things fizzle out and get
> orphaned, we need to be brave enough to park things and stop tracking
> continuous non-progress. Once we have that draft, we can publish it for
> community feedback and from there.
> 
> What do you think?
> 
> And attempting to answer you starting question: I think it's fine to move
> conversation about bhyve manageability into the weekly bhyve calls. The
> detailed and technical conversations were already happening there -
> there's no denying that. Reporting the big picture progress in the EWG (if
> there is any) would still benefit the community, but we should also admit
> it, if there is little progress and archive activities if they lack
> resources for the moment.
> 
> Holy wall of text Batman... anyone who's made it down here: congrats!

Thank you for the kind words Chris.

With the Production User calls predating the EWR and establishing to 
what appears to be a sustainable model that has fostered EWG/PUC 
cross-attendance, my takeaway is that the Production Users should 
further formalize our projects that seek funding as developers become 
available. Many of these projects are quite small by software 
development industry standards and fortunately the Foundation has a 
clear project proposal and funding mechanism once a project is formalized.

What is missing is a small budget to incubate fundable projects. 
Creating a Statement of Work takes time and subject matter expertise by 
individual developers, who typically not have the advantage of 
consulting company infrastructure (or disadvantage of the added cost of 
that infrastructure). This community-centric funding model is probably 
the most efficient available anywhere and gently crosses the 
volunteer/contractor line, rather than reaffirming the small user/big 
vendor divide that dominates many communities.

I have a loyal group that contributes from time to time but am currently 
incubating this work out of pocket. I will keep doing this and others 
are welcome to join. I encourage payments directly to developers because 
ultimately, I just want to return to simply being a user.

All the best,

Michael Dexter