Bug#848133: RFS: rdup/1.1.15-1.0
Am 24. Dezember 2016 12:57:37 MEZ, schrieb "Félix Sipma" <felix+debian@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+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
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
Reply to: