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

Will Sutton will at sutton-family.org
Mon Jun 7 13:32:23 BST 2021

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

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

On Mon, Jun 7, 2021 at 6:18 AM James Youngman <james at youngman.org> wrote:

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

No trees were harmed in the sending of this message, but a rather large
number of electrons were terribly inconvenienced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-bacula-devel/attachments/20210607/5bb36343/attachment-0001.htm>

More information about the pkg-bacula-devel mailing list