Hello Uwe, Am Tue, Feb 04, 2025 at 09:56:51PM +0100 schrieb Uwe Kleine-König: > >> If so I wonder further if > >> > >> Maintainer: Package Salvaging Team <[email protected]> > >> Uploaders: Ilyas Gasanov <[email protected]> > >> > >> is really suitable. > > > > It serves the following purpose: The original Maintainer remains > > responsible but every other member of the Package Salvage team can do > > some team upload if necessary. > > If I were in the situation that I would want to improve hyphen-ru but > want the original maintainer to keep being responsible, I'd propose an > NMU instead of salvaging because the latter's purpose is (IIUC) to take > away the package from the original maintainer when a new maintainer > has a honest interest in this package. Salvaging for QA like work feels > wrong to me.
I get your point. On the other hand the changes in Git go beyond what is usually done in NMU. Possibly we are seeking for some new formalism. My intention to leave the original Maintainer name inside the metadata is kind of some reference to previous work with the hope that might be continued later. We intend to discuss this in DebCamp - so if you have some ideas feel free to join. > > No. But unsupported debhelper compat levels are for instance. Do you > > think it makes sense to specify such QA issues, lintian issues etc.? > > I think being more verbose than "There are QA issues with the package" > would be good. I get your point as well. However, I have filed about 200 ITS bugs since August last year - and received less than 5% responses. So if I put some more effort into this item this will not be read in most cases and those who are interested can find the relevant items easily in the changelog of the Git repository. > The reason I asked for "maintained on Salsa" is that you mentioned that > as the focus of the Bug of the Day initiative and in my eyes that's not > something that needs fixing. The wiki page states that the criteria to > pick a package includes "No VCS or obviously outdated VCS" and VCS on > github (IMHO) doesn't qualify for that. The criteria in Wiki are very helpful to find packages that are somehow forgotten. I consider inclusion into Salsa a good move for several reasons - specifically if its about demonstrating a how to salvage a package. > Also if you want newcomers to learn from your changes, I'd say e.g. > > https://salsa.debian.org/salvage-team/hyphen-ru/-/commit/a42cdf20a5e509a19331cfc7e1a8f0a7b394a0da > > would benefit from a more verbose description than "Fix watch file" and That's true. However, what I need to admit is that the "Teaching newcomers" effort is way less successfully than I was hoping. On the matrix channel I repeatedly tried to encourage newcomers to ask questions and I was offering detailed explanations. As long as this is not the case I was falling back to what I consider "sufficient" commit descritions. I will report about my expectations and the results of the Bug of the Day effort at last at next DebConf. > I also don't understand > > https://salsa.debian.org/salvage-team/hyphen-ru/-/commit/35b3ddb5e3c786960f265d910d836538b850a9e4 > > . Good catch. For sure this is not a proper commit. I simply forgot to add the according lintian-override. Since I meanwhile had pushed the intermediate status (to check Salsa CI) I refrained from fixing the git history. So you found a mistake of mine I'm not proud about. Besides these hints, do you have other suggestions for enhancements? Kind regards Andreas. -- https://fam-tille.de
