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. 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 :-)). 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+debian@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
Attachment:
signature.asc
Description: PGP signature