Control: tags -1 pending Thanks Hi Ron,
as I announced in my mail two weeks ago I have some clear preference where to maintain this repository. Since I have not heard from you and your private repository did not enabled MRs yet, I have picked option 3. from below, transfered the repository to Debian team https://salsa.debian.org/debian/mp3splt and uploaded to delayed=15. Please let me know if I should cancel the upload. Kind regards Andreas. Am Wed, Jan 21, 2026 at 10:34:06AM +0100 schrieb Andreas Tille: > Hi Ron, > > I would like to help move things forward with mp3splt. > > I recently found your packaging repository on Salsa. I had missed it > before, as it is not referenced in the Vcs fields of the uploaded > package. Once I realised this I tried to contribute via a merge > request, but MRs are currently disabled. Thus I created a clone at > > https://salsa.debian.org/tille/mp3splt/ > > which preserves the full packaging history, incorporates past NMUs, > and includes the changes I previously prepared - at least the parts > that fit the new situation. > > During the recent discussion it also became clear that maintaining > mp3splt within the Debian Multimedia team is not the preferred option, > so I am proceeding under the assumption that the package should remain > maintained outside that team context. > > Based on your description of the maintenance model - namely that people > occasionally contribute improvements when they need the package - I > think it would be beneficial to make such contributions easier by using > a shared Git workflow on Salsa. > > Given that, I see the following options, listed in order of my personal > preference: > > 1. I move the repository to Debian team namespace, set the Vcs fields > accordingly, and you take it from there (including handling > #1122255, where your judgement clearly carries more weight). > > 2. You enable merge requests on your existing repository, and I submit > the current changes as an MR for your review and upload. > > 3. I move the repository to Debian team namespace, set the Vcs fields, > and upload the changes as an NMU (delayed=10), limiting myself to > closing #981158 and leaving #1122255 untouched for you. > > 4. As a last resort, I leave the Vcs fields unchanged and NMU as in (3), > leaving it to you to pick up the changes when convenient. > > My strong preference would be (1) since it makes collaboration explicit > and visible. If I do not hear back within the next two weeks, I would > plan to proceed with (3) in order to keep the package in a good state > for users. > > I hope this sounds reasonable and helps keep mp3splt sensibly > maintained. I'm of course happy to adapt if you prefer a different > approach. > > Kind regards > Andreas. > > > Am Mon, Dec 15, 2025 at 11:42:35AM +0100 schrieb Andreas Tille: > > [Closing the bug asking whether removal makes sense.] > > > > Hi Ron, > > > > first of all, thank you for taking the time to explain your perspective > > and for having maintained this package over the years. Your description > > of its maintenance model helped me understand the background much better. > > > > Am Sun, Dec 14, 2025 at 08:25:58PM +1030 schrieb Ron: > > > mp3splt is one of those tools that has a fairly narrowly defined job, that > > > you don't generally need to do every day, but when you do need to do it, > > > there really isn't any other tool made to do that job (or at least wasn't > > > at the time I needed and revived it, and I'm not off the cuff aware of any > > > change to that since). > > > > Fully agreed. I was not aware of mp3splt before encountering it via the > > Bug of the Day, and my attempt to work on it was made in good faith and > > out of genuine interest in the functionality it provides. > > > > > Since then, we've all got older and busier, and the mp3 container format > > > is no longer as commonly used as it was, though there are still plenty of > > > them in existence and I don't expect that to change any time soon. > > > > > > So this package hasn't got the sort of attention that it might if it was > > > something that had everyday use, or if I was the sort of person with so > > > much spare time on my hands that I was itching for busywork to do which > > > would have near to no real world consequence - and I'm very grateful to > > > the people who have stepped up from time to time to upload some > > > improvement > > > to it that scratches some itch of their own. > > > > My motivation was to contribute to such a package by improving its Debian > > packaging and by trying to put it on a footing that allows occasional, > > collaborative maintenance when needed. From my experience, having a shared > > Git repository on Salsa with more than one involved person often lowers > > the barrier for exactly this kind of episodic maintenance. > > > > > And I know we have the deletionists who think that kind of existence is > > > intolerable - but I know for sure that if I turn out to be the next person > > > who needs this, I'd be very glad to find the seed of what I need already > > > available, even if it needs a little sun and water to make it germinate > > > again. > > > > Just to be clear from my side: my original intention was never to argue for > > removal. On the contrary, I picked up the package because I consider it > > useful and worth keeping available to Debian users. The question of > > removal only arose later in the context of an RC bug about open CVEs and > > their visibility to users, not because I consider the package itself > > obsolete. > > > > > So if someone else wants to officially make themselves an uploader of this > > > then good contributions to it will be very welcome. > > > > Thank you for clarifying this. I take this as confirmation that my > > interest in the package, as expressed by commit 00e8654a[1], is welcome > > in principle, even if you disagreed with the way the process started. > > > > I have reverted that commit for now. Given the concerns raised in the > > discussion, I preferred to step back from this change until there is a > > shared understanding of the desired maintenance model. > > > > > If they don't, and it > > > still exists in the repo the next time that I am that person, and I'm > > > still > > > one if its listed uploaders, then I'll share my work with everyone else > > > by uploading it. > > > > My intention was explicitly to keep you listed as an uploader, unless you > > ask to be removed. I see this as a way of respecting and supporting people > > who have already invested time and knowledge into the package. > > > > > ... > > > Surely knowledge must precede any declaration of intent? > > > > I fully agree. What I intended to contribute was primarily Debian > > packaging work: fixing an open bug, addressing some issue in the > > upstream code (58f5e844), and updating metadata (including licensing > > information that was incomplete). I hope this demonstrates a serious and > > practical interest in the package, even if my knowledge of the upstream > > code is limited. > > > > > Sorry, but that's not really true. The issues were not 'unnoticed' > > > and not being actively developed is not 'bit rotting'. > > > > Thanks for the clarification. When I used the term “unnoticed”, I mainly > > meant that there was no bug tracking CVEs in a way visible to users. > > Your explanation in #1122255 provides exactly that missing context, and I > > consider it sensible and sufficient documentation of the situation. > > > > Based on this clarification, I am closing the bug that requested removal > > of the package. > > > > > So in the absence of someone else stepping up to the be the primary > > > point of contact for issues regarding this package, I'm happy to > > > continue on in that role. And this package does still have a > > > relevant (if somewhat niche) job that it performs which we have no > > > other equivalent replacement for that I'm aware of. > > > > That sounds good to me. I am happy that the package remains available > > and that there is still someone willing to act as a point of contact > > when needed. > > > > > I don't think it's right to try and foist it onto another team > > > that did not volunteer themselves willingly - but I don't think > > > the absence of such a team is a good reason to simply annihilate > > > it either. > > > > I agree that maintenance should not be forced onto any team. My attempt to > > work within a team context was meant as an offer to collaborate, not to > > shift responsibility unwillingly. > > > > To summarise my intent: I would like mp3splt to remain in Debian with a > > clearly communicated maintenance model and a Git setup that enables easy > > collaboration when needed. I would explicitly encourage cherry-picking > > from the Salsa repository I created, as it already contains packaging > > cleanups and documentation that may be useful going forward. > > > > It would be great to see an upload by an involved maintainer in the near > > future, as a visible sign of continued interest in the package. After a > > long series of NMUs that went unconfirmed, such an upload would help make > > the current maintenance situation clearer to both users and contributors. > > > > If you prefer a different repository location or workflow, I am of course > > very happy to coordinate. > > > > > All The Loves, > > > > Same > > Andreas. > > > > [1] > > https://salsa.debian.org/multimedia-team/mp3splt/-/commit/00e8654acea28878832a0cb113a0eb2ffc6a292f > > > > > > -- > > https://fam-tille.de > > > > > > -- > https://fam-tille.de -- https://fam-tille.de
