Hi Ron, good to hear from you.
10/11/2020 05:03, Ron :
> I can't say I'm a huge fan of format 3.0 (quilt), especially in this
> day and age where both the package and upstream are maintained in git,
> and doubly so for a package like this one, where I was able to upstream
> all the local patches it was carrying in about the first week that I
> started maintaining it ...
This may have been true in the past, but is not since 5.2+20150808-1.1
NMU. A file has been directly modified in the source instead of creating
a .patch. This is really confusing when one wants to understand the
differences between the Debian and the upstream version.
Format 3.0 (quilt) does not prevent oneself to upstream all the local
patches, so I do not understand this argument.
Speaking of "in this day of age", the fact that format 1.0 is getting
less and less used [1] is also why I am proposing the transition. This
will make new maintainers *and users* more comfortable in working with
the source package when needed.
[1] https://trends.debian.net/#source-formats
> So if you can be happy not to make major changes that are essentially
> gratuitous and don't actually add anything of value or fix any really
> existing problem (or at least not go down that road without first
> talking about what real advantage you think it might add), I would
> certainly be happy to see this package have all the people with a
> genuine interest in it helping to actively maintain it.
Quoting myself:
> I have reworked the package locally to fix almost all lintian warnings,
> moved format from 1.0 to 3.0 (quilt) and updated to the latest standards
> version. I already did a previous NMU (on top of another NMU) that
> fixed the IPv6 bugs. I received thanks from bug authors as it solved
> their issues (and mine too).
>
> I was originally trying to publish this big change as a NMU, but it
> would make more sense to first adopt the package and then make a proper
> -2 release instead of a 1.3 NMU.
Do you consider that fixing all lintian warnings and updating to the
latest standards version is not providing value nor "real advantage" to
the package? (and, to a certain extent, to Debian itself?).
> It is essentially a "finished" piece of software - it does the job
> of implementing the protocol - so mostly the only work it should
> need is when something external changes that breaks its environment.
> If you want to add yourself to uploaders and contribute to fixing
> real bugs with a Proper Maintainer hat on, I'd absolutely welcome
> that. Does that sound like a more long-term viable way forward on
> this one to you? It is the nature of this game for people's needs
> with packages like this one to be cyclical, and I'll guess it will
> be no different for you once your immediate need is scratched as
> well.
The reason I looked into this package at first was because of the
well-known IPv6 "real bug", reported on Sat, 29 Nov 2014 in #854077 [2]
but that was not fixed after years of debate. I did a NMU to do the
simple change proposed by the bug reporter, this made IPv6 work out of
the box and I was able to close 2 bugs (forgot to close this one).
Regular users of tftp-hpa thanked me for finally doing this change in
the default configuration file so that tftp-hpa now works out of the box
in IPv4 and IPv6.
Getting back to the ITS request.
Out of the salvaging checklist [3], this package meets 3 of the 4 OR'ed
requirements:
* NMUs, especially if there has been more than one NMU in a row. (2 in
a row)
* There are QA issues with the package. (lintian warnings which are
"gratuitous" your words)
* Bugs filed against the package do not have answers from the
maintainer. (you refused to fix IPv6 bug from 2014 to 2020)
I am not genuinely interested in maintaining tftp-hpa for the sake of
being its maintainer. I just want to provide major improvements (term on
which we seem to disagree) like fixing bugs and upgrading the package
from 2014 to 2020 standards. This is why I originally proposed an NMU,
but all of these changes probably need a new Debian release number
according to peers. Being co-maintainer could be fine, but we need to
agree on what is important to Debian and what is not.
If you reject this ITS, what are your plans for the future of tftp-hpa?
Maybe the software is done, but in my opinion the packaging is not (cf
lintian, format, etc.).
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854077
[3]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-a-package-is-eligible-for-package-salvaging
Best regards,
Romain.
signature.asc
Description: OpenPGP digital signature
