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

[James Youngman]

I waited a while to give time for people who didn't immediately see
this thread to chime in.  I hope everybody who wanted to has now had
that opportunity.

I think we have a rough consensus on what we'll do.  There are also
some things which seem reasonable but which we didn't discuss yet that
we should agree on.   Here's what I think we're agreed on:

1. We should create or select a git repo where master corresponds to
the stable release, plus patches approximately representing the
consensus choice of a few Linux distros [see item (b) below].  That
is, where we can identify patches in use in (more than one of) Red Hat
/ Centos / Debian we should adopt those into master.
2. We should adopt a project structure with multiple active
maintainers.   Will and I have, I believe, already volunteered.
Anybody else?
3. Our initial focus should be on showing clear signs of life and
helping distros switch over to our now-actively-maintained upstream
project.  This should be prioritised over feature development (we can
use, for example, a branch such as "next" for feature development).
This doesn't mean "no feature development" though, it's just not the
most important aspect, initially.

If we actually don't have a consensus on 1-3 above, please voice your concern.

Things we have not yet discussed fully, but need to agree on:

4. How will we structure our maintainers team?   It seems reasonable
to use a free-tier (as in $0) Github Organization
(https://github.com/organizations/plan).    That allows the
organisation to have multiple "owners" and yet still costs nothing.
I'm against the idea of using an individual's repo because it would
mean that, once again, we'd have a single point of failure if that
individual becomes inactive.  But I'm sure there are multiple ways to
solve this part of the problem.   Opinions?
5. Naming is something we've not discussed.   If we create an
"organisation" per (4) above for this, that forms a useful
qualification to distinguish this version of mtx from the predecessor,
but then we will need a name for the team/organisation.   Suggestions
anybody?
6. What forum will we use for discussion?   Keep the existing
SourceForge mtx-general list?  Or something new?   (my opinion on this
is that using mtx-general might generate uncertainty about the status
of what we're doing which is basically a fork)

Some other things I think need a volunteer but aren't likely to be contentious:

a, Do we have any contacts with teams working with much larger
libraries?   Folks on this thread seem mostly to be using LTO
libraries in the 24-48 slot range.   It would be good to be able to
get occasional testing feedback from libraries having many more slots,
so I think we should try to find collaborators (even if just for
occasional testing) who have large libraries.    We could use a
virtualised large library with iSCSI I suppose, but even setting those
up is non-trivial.   Testing help from someone having a linear-only
tape changer device would probably also be good.

b. I think we should map out which baseline and which patches are
currently in use in each distribution, so that our initial "master"
branch doesn't include code changes likely to be perceived by dsitros
as "risky".   I'm willing to look into this but if someone already did
some of this work, that would be great.



On Tue, Jun 1, 2021 at 2:21 PM Will Sutton <will at sutton-family.org> wrote:
>
> James,
>
> I am interested in keeping this project moving forward. The code seems very stable and mature, and my day job takes me more into the C an C++ side of things, so I can be a more competent maintainer as well. I have no problem sharing ownership with the right maintainers to keep it alive.
>
> I've been using this repo on arch for quite a while with my TL4000 and not encountered any issues.
>
> That being said, I've not heard anything from the original author since I created this repository.
>
> Carsten, I pulled your patches into their own branch. I think it should be identical to the debian branch at this point. Feel free to send me any additional patches I might be missing.
>
> I pulled my repo in from here: https://sourceforge.net/p/mtx/code/HEAD/tree/branches/stable-1.3/
>
> At this point, the latest code is from soruceforge is 13 years old.
>
> I'd be thrilled to open dialog with the rest of you as well.
>
> William Sutton
>
> On Tue, Jun 1, 2021 at 6:15 AM Carsten Leonhardt <leo at debian.org> wrote:
>>
>> Hello all,
>>
>> I'm the Debian mtx package Maintainer.
>>
>> James Youngman <james at youngman.org> writes:
>>
>> > I'd really like us to get to a place where there was a
>> > community-driven and group-managed upstream project (so that we're not
>> > singly-homed on one maintainer any more) where at least initial
>> > releases are conservative in their changes, to encourage distributions
>> > all to select the same upstream.   Right now, I don't have opinions on
>> > what the basis (e.g. what repo) for that should be, and I'm aware that
>> > naming might need some careful consideration.
>>
>> as far as I can see, most distributions have based their mtx package on
>> the last stable version from Robert. I've tried to find all patches that
>> other distributions use and added them to the Debian package. Later I've
>> submitted them to Will for inclusion, but the version in Will's
>> repository is based on Robert's development branch.
>>
>> From my point of view I'd prefer starting from Robert's last stable
>> version plus the generally accepted patches.
>>
>> The patches applied for the Debian package can be found here:
>> https://salsa.debian.org/bacula-team/mtx/-/tree/master/debian/patches
>>
>> Regards,
>>
>> Carsten
>
>
>
> --
> No trees were harmed in the sending of this message, but a rather large number of electrons were terribly inconvenienced.