Hi Holger,
Am Thu, May 08, 2025 at 08:07:35AM +0000 schrieb Holger Levsen:
On Thu, May 08, 2025 at 10:00:10AM +0200, Andreas Tille wrote:
From my point of view, orphaning would be a more forceful step--closer in spirit to a QA upload, as Holger suggested. I prefer a gentler path that allows space for maintainers to re-engage if they wish.
again, orphaning means doing a QA upload. a gentler path would be an NMU. again, I don't why we need a new process here.
Orphaning is something typically done by the maintainer themselves[1].
If someone else does it unilaterally, wouldn't that come closer to a
hijack? There's precedent for "Intent to orphan packages with
unreachable maintainer address"[2]--but of course, that assumes attempts
to contact the maintainer have failed.
Would it feel more appropriate if I called it ITO (Intent to Orphan)
instead of ITN and use the 21 days waiting period + upload to
delayed=10?
Quoting Andreas Tille (2025-05-08 10:26:08)
Orphaning is something typically done by the maintainer themselves[1].
If someone else does it unilaterally, wouldn't that come closer to a hijack? There's precedent for "Intent to orphan packages with
unreachable maintainer address"[2]--but of course, that assumes attempts
to contact the maintainer have failed.
Would it feel more appropriate if I called it ITO (Intent to Orphan) instead of ITN and use the 21 days waiting period + upload to
delayed=10?
Yes, that helps tremendously.
That makes is clear that we are talking about an aim of taking away maintainership, where we can then sensibly discuss what are the costs
for the maintainer in complying or non-complying with the request, and
the costs for the project in having this procedure and not having it.
That avoids confusing arguments like "it has no cost to the maintainer"
or "we already have that procedure established", because it is clearly something specific and different from both NMU, ITA and MIA.
Thank you for clarifying. I have taken the liberty of renaming the
subject field, and hope we can move on with a more focused discussion onwards,
How about a BoF on strong package ownership in Brest?
Quoting Andreas Tille (2025-05-08 10:26:08)
Would it feel more appropriate if I called it ITO (Intent to Orphan) instead of ITN and use the 21 days waiting period + upload to
delayed=10?
Yes, that helps tremendously.
That makes is clear that we are talking about an aim of taking away maintainership, where we can then sensibly discuss what are the costs
for the maintainer in complying or non-complying with the request, and
the costs for the project in having this procedure and not having it.
That avoids confusing arguments like "it has no cost to the maintainer"
or "we already have that procedure established", because it is clearly something specific and different from both NMU, ITA and MIA.
Thank you for clarifying. I have taken the liberty of renaming the
subject field, and hope we can move on with a more focused discussion onwards,
- Jonas
P.S. It was genuinely not obvious to me that you meant Intent To Orphan.
I read multiple potential intentions into your experiment and see
indications in this thread that others did too.
It
just hides the fact that they are unmaintained and makes it therefore
harder to find stuff that should be orphaned and/or removed.
Just a short comment: In the Bug of the Day effort the majority of
packages will be moved into team maintenance using the ITS procedure or packages removed via (pre-)removal bugs.
Hi,
Am Thu, May 08, 2025 at 06:48:33PM +0200 schrieb Andreas Metzler:
It
just hides the fact that they are unmaintained and makes it therefore harder to find stuff that should be orphaned and/or removed.
Just a short comment: In the Bug of the Day effort the majority of
packages will be moved into team maintenance using the ITS procedure or packages removed via (pre-)removal bugs.
How do you go about that? Do you poll the respective team whether they
are committing to maintain it?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 145:48:50 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,687 |