Hi Tobias,
Am Mon, Jan 06, 2025 at 10:30:04AM +0100 schrieb Tobias Frost:
On Mon, Jan 06, 2025 at 09:19:26AM +0100, Niels Thykier wrote:
Rather than inactive maintainers. For inactive maintainers, we have the ITS process, which I believe is working (at least better than what we had before
the ITS process).
When introducing the process ad Debconf18 in Taiwan, IIRC one person in the BoF
suggested to relax or amend the ITS process, my answer was kind like "we should first try it and then we can make an iteration (not quotes, just
out of the back of my brain; didnt rewatch the recordings)
Thanks a lot for driving this process in the first place.
Maybe the time to start this discussion is now?
Six years experience seem to be a good basis for refreshing the discussion.
What are the shortcomings? How can we adjust / tune the ITS process to
make it even more useful.
Personally, my main challenge is having to focus on the same issue
twice, with a minimum delay of 21 days in between. For example, I
encountered an ITS bug that had been lingering in the BTS for over a
year. The waiting period is entirely reasonable under our current
understanding of package ownership, as it allows the maintainer
sufficient time to respond. Shortening this waiting time might have
limited impact, as the person initiating the salvaging process still
needs to set a calendar reminder. I’m unsure how to improve this aspect within the ITS process.
Another challenge is the inability to indicate that you have enough time
to help a maintainer resolve specific issues in a package without
committing to its long-term maintenance. Examples include packages not
migrated from Alioth to Salsa, missing or invalid Homepage or watch
files, etc. I’ve seen NMUs addressing issues like switching to source
format 3.0, and the delayed queue currently contains many fixes for Rules-Requires-Root. These NMUs focus on specific technical improvements we’ve agreed upon. However, they typically avoid addressing issues like broken or insecure Homepage URLs, outdated Standards-Version, or
unsupported debhelper compatibility levels.
As refererence, for background on thoughts of the process: https://lists.debian.org/debian-devel/2018/07/msg00453.html
ITS 2.0 would be a good DebCamp Project for Brest, so partners in crime
would be very welcome.
I’d be happy to join you at DebCamp in Brest to discuss this further. However, I’m not convinced that refining the ITS process alone would
address the challenges I have in mind. Instead, we might consider
refining the criteria for interacting with a package. For instance, we
could establish specific criteria such as:
1. X (e.g., 3) NMUs in a row, provided the subsequent NMUs are
unrelated to the initial ones. (similar to current criteria)
2. Use of a deprecated debhelper compatibility version.
3. Standards-Version predates the release of the current old-stable.
4. Not uploaded by the Maintainer for X (e.g., 5) years or since the
release of old-stable.
5. ?
In my opinion, we provide a valuable service to our users by allowing activities such as refining packaging metadata, upgrading to the latest packaging standards (Standards-Version, debhelper level, lintian fixes),
moving packages to Salsa, fixing random bugs, upgrading to the latest
upstream version, or adding autopkgtests—essentially tasks that the
official maintainer is expected to handle but which are not typically permissible in NMUs. Of course, anyone making these changes should take responsibility for addressing any issues that arise as a result,
ensuring the package is monitored and fixed if needed. However, such contributions should not imply a long-term commitment to the package, as defined by the ITS process.
I fully understand that this approach should not apply to all packages.
It might be reasonable to restrict it to packages with 'Priority:
optional' (and those still using the deprecated 'extra' priority, which
could be updated to 'optional' during this process). Maintainers should
have the ability to blacklist their packages from such procedures, as I suggested in [1], or through any improved method we can agree upon. This
would shift the current approach from whitelisting packages (via
lowNMU), which requires maintainers to actively enable participation, to blacklisting, which would require maintainers to actively opt out.
I'd be happy to discuss this in more detail in Brest.
Kind regards
Andreas.
[1]
https://lists.debian.org/debian-devel/2024/12/msg00101.html
--
https://fam-tille.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)