<div dir="ltr"><div><div>I don't think that the per-distro-patch repo is a bad approach. If you look at the debian patches, half of them are formatting and spelling. There is little meaningful code change aside from some better error reporting on the user side. <br><br></div>Yes, there would be a number of VMs to test with, perhaps we can support a subset of distros (Debian, Cent, Suse, RedHat, Ubuntu, Arch) and then if others want to be added to the list, we can address it then. This would all be temporary as upstream gets caught up with whatever everyone had to do to function. I suspect we could knock out 80% of the existing patches for those 6 distros by the end of the summer if they were all in their own branches. <br><br></div>I'd agree that we'd be better off with more than one dev, maybe even more than two. If we start getting more traction, we could expand past that. I contribute to HomeAssistant and to Zigbee2MQTT so I understand the sea of small developers aspect as well. <br><div><br></div><div>I think a next branch is a good idea, but I think the flow should be User presents issue -> Code branched per issue/PR -> Tests -> Merge to main with version bump -> PR and branch closed. Rather than a rolling next branch.<br><br></div><div>I think I can set up an organization in a structure I'm comfortable with. I'm concerned with putting together all this work and someone running off with the repo after everyone points to it as upstream. <br><br></div><div>By on the repo, I mean a mix of "Issues" and "Pull Requests" rather than mailing lists that can be intimidating to new users. <br><br></div><div>P.S. I think I may have found a recent contact point with Robert. I'm reaching out and will report back if he responds. <br><br></div><div>Will<br></div><div><br> <br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 7, 2021 at 3:35 PM James Youngman <<a href="mailto:james@youngman.org" target="_blank">james@youngman.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 7, 2021 at 1:32 PM Will Sutton <<a href="mailto:will@sutton-family.org" target="_blank">will@sutton-family.org</a>> wrote:<br>
><br>
> 1) My repo is based on the latest stable. At this stage, I think we create branches for each distro that has their own patches, and slowly work through them merging into one main.<br>
<br>
My  concern about a branch-per-distro approach is that it's complexity<br>
taken on at the beginning to (I suppose) avoid a problem that I'm not<br>
sure we know we have.   Given the length of time distributions can<br>
take between releases, those branches may live longer than we prefer.<br>
<br>
If we were to offer a branch per distribution, I'd end up with a lot<br>
of VMs to manage just to regression-test commits to each branch.   I'm<br>
not familiar enough (yet) with LIO to know how complex it would be to<br>
plumb my actual library hardware through to each VM in order to run<br>
the tests.   Right now this sounds to me like an avoidable complexity.<br>
<br>
Distributions are better placed to manage patches than we are to<br>
manage a branch per distribution, I suspect.<br>
<br>
> 2) I think given the age and maturity of this project, we don't need very many other maintainers. In fact, adding too many may invite a "too many cooks in the kitchen" scenario.<br>
<br>
I'm not suggesting adding maintainers for the sake of it.   I'd rather<br>
start with N maintainers than with N divergent implementations.  It's<br>
easier to achieve consensus among N people than it is to merge N<br>
separate projects.  Personally I've worked on open source projects<br>
with as many as 6 maintainers without any "too many cooks" problems<br>
that I recall.<br>
<br>
> 3) I agree on the "next" or "dev" branch, the question is what features are desired, or what problems need to be addressed? I'm not saying its fine as is, but I'm not seeing many complaints either. I'm not sure how to show signs of life, other than reaching out to distro maintainers and getting their repos pointed to the right place.<br>
<br>
I would say that mostly feature planning for "next" is a question for<br>
later.  That is, having no specific plans right now for "next" is not<br>
a problem.  The one thing I'm aware of now that comes under this<br>
heading is probably paging support (i.e. querying slots in batches to<br>
avoid problems with long responses from large libraries).<br>
<br>
> 4) I may be biased in this one, but given the infrequency that MTX needs to be updated, coupled with its niche audience, I don't think we need to go through the hassle of creating an infrastructure, especially since there is an "Invite a collaborator" option on github. I'm not planning on dying any time soon, nor do I have any extreme sports hobbies. If I drop off the face of the earth, the community can always find another solution.<br>
<br>
We're facing exactly this situation right now.  We have an existing<br>
maintainer who, as far as I can tell, gives every appearance of having<br>
dropped off the face of the Earth.   I'm sure that when he started as<br>
maintainer, Robert would have said he didn't expect to drop off the<br>
face of the Earth either.  Two of the other free software projects I<br>
already maintain I've ended up maintaining because the prior<br>
maintainer in one case did figuratively drop off the face of the Earth<br>
and in the other abandoned the project.<br>
<br>
For me the whole point of the exercise is to rescue the project from<br>
its current state and fix things up so that there isn't a single point<br>
of failure any more.<br>
<br>
> 5) We should not change the name at all. MTX is well known, well documented, and changing the name risks turning people off from all the very good documentation and examples already present online.<br>
<br>
I agree.<br>
<br>
> 6) Discussion is easy. It happens on the repo. No where else. Maybe an IRC channel. We should assume that the people that use this software are technically competent given the cost and complexity of the equipment.<br>
<br>
Not sure I understand what you mean by "on the repo" here.<br>
<br>
<br>
><br>
> a) I think if we need more testing, we should reach out to major corporate partners. Again though, I'm of the opinion that no news is good news. I think most large libraries operate the same way, there is a changer device, and an arbitrary number of read/write devices.<br>
> b) See #1<br>
<br>
James.<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr">No trees were harmed in the sending of this message, but a rather large number of electrons were terribly inconvenienced. </div>