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
