Hi Fabio, Am Sat, Nov 25, 2023 at 07:33:32PM +0100 schrieb Fabio Fantoni: > Il 25/11/2023 18:10, Tobias Frost ha scritto: > > This seems a bit ouf of scope for an NMU (new upstream releases are > > NMUed only in exceptional cases) and #998105 is severity normal and > > #973760 is severity minor. (Please see the developers reference about > > NMUs. > > > > Do you have additional information why this should be an NMU? > > I'm seeing you are member of the repo, should your name be added as > > Uploaders and this be a regular upload? > > Did you reach out to the maintainers and get an ACK from them? > > > Hi, thanks for reply. I recently did some help on this package because I use > it, so when I see cases with issue and/or new upstream version (with useful > things) where a lot of time passes I try to help if I have time. > > even if #998105 is only set "normal" is "a regression" that make users that > backup over ssh waste time to found the workaround, I tried also to be fixed > for bookworm (before release) with a upload with only this fix > (https://salsa.debian.org/jmw/pkg-backintime/-/commit/0066cffd98aa09c5528cb94abedda5a1a5e59e3e) > but was rejected by the maintainer, then he replied to me who just wanted to > wait for the bookworm release and have additional things before making a new > upload. so I gave up and waited until after the new upstream version came > out (and I still waited another month before doing anything)
It seems that commit was done during or just before the hard-freeze, and thus not acceptable as per release policy. The problem's severiy "normal" seems to be appropiate, too. > Although it is not such a long time or with such serious bugs from the > general point of view of debian, some upstream developers and users have > come to consider this package as abandoned, here is an example: > https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2039271 (anyway > In that case it would not have been possible to upload the new upstream > version anyway as that Ubuntu version was in freeze) (Ubuntu != Debian.) And as you say on the launchpad bug, 4 uploads a year well means this package is maintained. > > I would prefer a normal upload (from the maintainer), already prepared and > tested, it also saves time, but unfortunately as I wrote at the moment I > have not received any response and I had only been given permission for the > repository previously where I already started to prepare for new upload one > month ago. I also write to upload with delay for give another possibility to > the maintainer, if he will have time > > regarding the maintainers list I think it would be good to have it in the > debian python team but doing this or possibly adding me as co-maintainer is > a choice of the current maintainer. however I can't guarantee that I would > have enough time to follow it and make quick enough uploads when needed in > the long term. > > If the maintainer responds to me in the future I will ask if he wants do > something. thanks for your explanations. Unfortunatly, I fear that your NMU is outside of the scope of NMUs, despite the good intentions you have. NMUing a new upstream version is only appropiate under certain conditions. For example it is preferred to have dedicated patches to fix problems (but not during a freeze, of course) So if you come up with dedicated fixes, this NMU can go forward, otherwise, I fear, not, unless the maintainer actively acked. (There is also no bug that expressed the intention that you are going to NMU on the package's BTS) Other option would be to invoke the ITS process, but I'm not sure (as in I did not check in depth),whether the package would be eligble. Of course, you will have to commit to the maintainance of the package then. (But a NMU does also, albeit not to the same extend.) -- tobi
