[pkg-bacula-devel] Does the mtx package still have an "upstream" maintainer?

[James Youngman]

On Mon, Jun 7, 2021 at 1:32 PM Will Sutton <will at sutton-family.org> wrote:
>
> 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.

My  concern about a branch-per-distro approach is that it's complexity
taken on at the beginning to (I suppose) avoid a problem that I'm not
sure we know we have.   Given the length of time distributions can
take between releases, those branches may live longer than we prefer.

If we were to offer a branch per distribution, I'd end up with a lot
of VMs to manage just to regression-test commits to each branch.   I'm
not familiar enough (yet) with LIO to know how complex it would be to
plumb my actual library hardware through to each VM in order to run
the tests.   Right now this sounds to me like an avoidable complexity.

Distributions are better placed to manage patches than we are to
manage a branch per distribution, I suspect.

> 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.

I'm not suggesting adding maintainers for the sake of it.   I'd rather
start with N maintainers than with N divergent implementations.  It's
easier to achieve consensus among N people than it is to merge N
separate projects.  Personally I've worked on open source projects
with as many as 6 maintainers without any "too many cooks" problems
that I recall.

> 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.

I would say that mostly feature planning for "next" is a question for
later.  That is, having no specific plans right now for "next" is not
a problem.  The one thing I'm aware of now that comes under this
heading is probably paging support (i.e. querying slots in batches to
avoid problems with long responses from large libraries).

> 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.

We're facing exactly this situation right now.  We have an existing
maintainer who, as far as I can tell, gives every appearance of having
dropped off the face of the Earth.   I'm sure that when he started as
maintainer, Robert would have said he didn't expect to drop off the
face of the Earth either.  Two of the other free software projects I
already maintain I've ended up maintaining because the prior
maintainer in one case did figuratively drop off the face of the Earth
and in the other abandoned the project.

For me the whole point of the exercise is to rescue the project from
its current state and fix things up so that there isn't a single point
of failure any more.

> 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.

I agree.

> 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.

Not sure I understand what you mean by "on the repo" here.


>
> 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.
> b) See #1

James.