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

Wed Jun 9 18:39:40 BST 2021

Alexander,

Your code changes look good as a cursory glance. In the changes you made,
do you think it would continue to function in its original manner as well
as being callable from C and Python? If so, we could combine efforts. I
have a feeling my .edu employer and .gov sponsor would be interested in
this as well.

Will

On Wed, Jun 9, 2021 at 11:43 AM Alexander Moibenko <moibenko at fnal.gov>
wrote:

> We, at FNAL, for instance, use TS4500 LTO8 libraries with 10000 slots and
> tens of tape drives. The modified mtx code allows effective use of such
> library.
> Alexander
>
> > On Jun 7, 2021, at 5: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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_organizations_plan&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=uCieIOAHwHSoalWGwfwXnb1j63Xofn_y7IK_3EmVWv4&e=
> ).    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://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_mtx_code_HEAD_tree_branches_stable-2D1.3_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=HkkYGzm8ObarTEbetswkNkCWneqHRfPRq4NTuekc-wU&e=
> >>
> >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_bacula-2Dteam_mtx_-2D_tree_master_debian_patches&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=ke0-ii-UBkDvd0HwwF_1Ly4E6zf8xuMoGsd5CnqXzR8&e=
> >>>
> >>> 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/20210609/62efd22b/attachment-0001.htm>