Am 24. Dezember 2016 12:57:37 MEZ, schrieb "Félix Sipma" <felix+deb...@gueux.org>: >Hi Tobias and Jose, > >I get your remarks Tobias, thanks again for your detailed reviews. > >If a NMU is out of scope for a lot of my changes, wouldn't be easier to >just >change the maintainer to QA (or me)? No offense is intended, it's just >that >doing a NMU and then another upload with the other changes would take >time to >me, to sponsors, ftp-masters, etc. This new version of the package >would have >the same problem as we have now: a NMU will still not be applicable.
NMUs are to fix bugs. Most of your entries would be in scope if there would have been a bug filed (eg by you).. But without bugs filed and without a nmudiff sent to BTS it is hard to justify an NMU. (Also such a big NMU days before the freeze is dangerous. This discussing is a few months late.) Changing the maintainer is also an option but needs also to follow the procedures. I cannot orphan packages "just on request".. The process to be followed is the MIA one and this will eventually result in the maintainer resuming or in a orphaned package, but the process will take time and cannot be rushed... I know you're eager to fix rdip but it wouldn't be fair to Jose of I allow* you to hijack this package. Jose: You can also write now that Félix can be (Co-)Maintainer... This or an upload from your side would be the best for the Debian project. * I would also not in the position to do so. >I can of course work to improve the commit messages, but I don't want >to waste >our time if it's not necessary. I get that it probably means that we >won't have >1.1.15 in stretch, but I I guess it would be hard now (I've not been >able to >be as fast as I wanted to be :-)). > I won't be able to sponsor the upload before the Stretch window closes. What I can offer is to do an appropriate NMU soon or you wait for the outcome of the MIA process in a few months. >On 2016-12-20 07:06+0100, Tobias Frost wrote: >> Hi Félix, >> >> Jose: If you read this, pretty please respond to this RFS and if >you'd >> ACK its content. >> >> Am Montag, den 19.12.2016, 15:05 +0100 schrieb Félix Sipma: >>> Control: tags -1 - moreinfo >>> >>> Hi Tobias, >>> >>> On 2016-12-18 22:24+0100, Tobias Frost wrote: >>>> (I won't sponsor this because I will not find time to do so before >>>> the >>>> Stretch-Window will close, except you'll be very fast in providing >>>> an >>>> updated package; Any other DD can/should grab this package if >>>> wanted) >>> >>> I'll try to be as fast as I can :-). >>> >>>> some remarks: >>>> >>>> - d/changelog does not contain the changelog entry of the NMU >>>> 1.1.11- >>>> 1.1 and seems so also not the changes by this NMU >>> >>> Sorry about this! I guess I just imported the package from the >>> maintainer VCS. >>> I've added the changelog entry, but not the patch, as it is not >>> needed anymore. >> >> Ok. You should always make sure that the VCS reflects that state in >the >> archives, especially if there have been NMUs it happens that the >> changes have not been pushed. >> >> A few reommendations for your d/changelog: >> - Changelog entries should be sorted accoring to their importance. >> For example, The "new upstream release" entry is quite important, it >> should go just below "Non maintainer upload" (which is always the >first >> entry on NMUs) >> - The ones related to the new upstream release (I guess the removal >of >> the patches is) should be below this "new upstream release" and >> indented. Like >> * New upstream release >> - patch_xyz intergrated upstream, removed. >> (only of course if this is the reason why it is no longer needed... >> Otherwise it would be interesting *why* it can be removed, because >> *that* it has been removed can be derived from the diff. >> >>>> - there is no announcement of the NMU on the BTS. Did you try to >>>> contact the Maintainer? >>> >>> As stated in the RFS, I did this privately two weeks before I filled >>> the RFS. I >>> can forward it there if needed. That's my first NMU, so I'm not sure >>> about the >>> announcement on the BTS. What should I do there? >> >> As already written by Alexander, check out >https://www.debian.org/doc/m >> anuals/developers-reference/pkgs.html#nmu >> For the announcement, you might find the nmudiff tool handy. >> >> As you can read here, your NMU changes a lot which should not be >> changes in the scope of a NMU. The problem is that a NMU should only >> fix (filed) bugs, not do cosmetic stuff. >> I know you were eager to fix as much as possible, but I guess all the >> nice fixes has to wait a bit**, so we should focus on the essential >> changes; lets briefly assess this, I take your changelog as basis >> (see, verbose changelogs helps....) >> >> rdup (1.1.15-0.1) unstable; urgency=medium >> >> * Non-maintainer upload. >> >> * enable hardening flags >> out of scope >> >> * add missing CPPFLAGS reported by blhc >> * add missing CFLAGS reported by blhc >> both: if this is not causing a FTBFS -- out of scope. >> >> * add patch to fix manpage formatting warning: >> 0002-fix-manpage-formatting-warning.patch >> out of scope >> * use DPKG_EXPORT_BUILDFLAGS in debian/rules >> out of scope >> * add rdup-simple.1 manpage >> out of scope -- file your manpage as bug >> * use dh_prep >> out of scope if not causing FTBFS (does it?); also a why would not >hurt >> here. >> * add patch fixing spelling errors: 0001-fix-spelling-errors.patch >> out of scope >> * bump debhelper compat to 10 >> out of scope >> * update Standards-Version to 3.9.8 >> out of scope (and you would also tell in the changelog if (and what) >> changes would be required. >> * add debian/rdup.manpages >> out of scope >> * update homepage (Closes: #771478) >> ok -- as it fixes a bug >> * update Vcs-Git and Vcs-Browser tags >> out of scope >> * add autoreconf to debian/rules >> out of scope unless it FTBFS (on certain archs) >> * add debian/watch file >> out of scope >> * removed 0001-Delete-set-but-unused-variables.patch (not needed >> anymore) >> OK -- it would FTBFS otherwise, I guess. >> * removed 0004-libarchive.patch (not needed anymore) >> OK >> * New upstream version 1.1.15 >> OK -- though borderline and only in those cirumstances**. Usually >this >> would warrant a NMU to ~ DELAYED/10 minimum, (even if on LowNMU) but >> then we won't reach Stretch. Lets bend the rules this time (only), >I'll >> take the blame... >> >> -- Félix Sipma <felix+deb...@gueux.org> Mon, 12 Dec 2016 16:30:16 >> +0100 >> >> ** I think the maintainer is inactvie and I started already to >> investigate (MIA team hat on) >> >>>> - the changelog should be more verbose. E.g "remove unused patch" >>>> -- should list which ones? There are undocumented changes. >>> >>> I fixed this in the new package I just uploaded to mentors. >> >> thanks for doing that. That helped a lot. >> >>>> -- CFLAGS += `dpkg-buildflags --get CPPFLAGS` looks wrong >> >>> What should be set there? I added this because I had a warning by >>> blhc during >>> the build related to this, and the doc I found about hardening build >>> flags >>> recommended to add this. >> >> It should probably CPPFLAGS += .... >> >>>> (please remove the moreinfo tag once the package is improved. >>>> Please make sure to try to contact the maintainer, best using the >>>> BTS) >>> >>> I added Jose in Cc: of this email. >>> >>> Thanks for your review, and I hope you'll find time to answer my >>> questions! >> >> As said, thanks for your eagerness to bring the package back to the >> state of the art, this is very appreciated... But the rules for a NMU >> are that it shouldn't do that much of fixing, (especially not days >> before the freeze.) >> >> Can you prepare something more minimal? >> And please file your remaining fixes as bugs to the BTS. It would be >a >> shame if they are lost (and with bugs in the BTS we could also fix >them >> per NMU -- but that won't work for Stretch anymore unfortunatly.) >> >> -- >> tobi Hi Félix, im currently away from home so appologize my brefity. -- Tobias Frost GPG fingerprint: 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
