Fathi Boudra <fabo@debian.org> has retired, so can't work on
the clucene-core package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Hallo,

When I filed the bugs in respect of the maintainer status of Fathi I used the wrong switch in the
script. I'd like to correct that.

Fathi has NOT retired, so the sentcne Fathi having retired is wrong.

it should have read

Fathi Boudra <fabo@debian.org> has not been working on the $PKG package for
quite some time.

I'm sorry for the inconvenience.

Hi Daniel,

Would you like to step up as a maintainer for clucene-core?
Else, please orphan the package.

Thanks,
Bastian

Hi,

I'd like to propose some procedure for packages that appear to lack
active maintenance, but where no formal orphaning has taken place.  Lets
have a look for instance at clucene-core:

  1. High popcon[1]
  2. Important rdepends like libreoffice-core
  3. Maintainer was contacted in #879296, but there has been no response
     recorded there; the last upload was nearly ten years ago
  4. Uploader was asked about interest to become Maintainer four
     years ago with no response[2]
  5. Open bug with patch to solve reproducibly problem #1059805
     requested by libreoffice maintainer with no progress since
     nearly two years
  6. Package was NMUed three times in a row (one 64-bit time_t,
     others to fix RC bugs)

One possible solution to consider would be to move the package to Debian
Commons maintenance, host it in the Debian team on Salsa, and upload the
change with a delayed upload to allow objections.  For the example above
I prepared this in

https://salsa.debian.org/debian/clucene-core

This example should simply give some evidence that we might need some
solution which does not block contributors to invest some time into
packages.  While another NMU would address the immediate issue, it would
not improve the long-term maintenance situation of the package.

Since this is not the only example we have I would like to go beyond
this example and start a discussion about criteria under which a move to
Debian Commons maintenance could be proposed.  (BTW, thanks a lot to
Paul for this suggestion which enabled me to have finally all my
packages team maintained.)

Possible criteria might include:

  * no maintainer upload for N years (combined with unsuccessful contact
    attempts)
  * repeated NMUs
  * unanswered contact attempts
  * pending fixes from contributors
  * importance of the package within Debian

Are these reasonable indicators, and are there others that should be
considered?  The delayed upload would provide another opportunity for
any interested maintainer or uploader to object, participate, or take
over maintenance.  The Debian Commons maintenance model is also easy to
reverse if an existing maintainer returns or another person volunteers
to take over primary responsibility for the package.

The goal is not to replace maintainers who are still interested in their
packages, but to provide a straightforward path to propose ongoing
maintenance when there is no active maintainer involvement.

Debian already has contributors willing to maintain such packages. The
question is how we can provide a clear and scalable path for those
contributors to assume ongoing responsibility when traditional
single-maintainer maintenance has effectively become inactive.

Kind regards
    Andreas.

[1] https://qa.debian.org/popcon.php?package=clucene-core
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879296#15
[3] https://qa.debian.org/developer.php?login=team%2Bdebian%40tracker.debian.org
https://lists.debian.org/debian-devel/2026/05/msg00105.html

That's the important question needing to be answered. Everything else
might be indicative, and probably these packages are important - but
why is the process that we have not working?

Is this an attempt of a workaround for the orphaning?

Best,
Chris

PS: I think the time_t-64bit NMUs should not be counted for this
purpose.

Hello Andreas,

thank you very much for picking up this topic. I am just an upstream
maintainer
but also in high interest in the Debian packaging process and
communication
between Debian and upstream.

Am 05.06.2026 14:30 schrieb Andreas Tille:

Interesting. I was not aware of this option.

This measures the timespan between "now" and the last upload. Would it
be
more meaningful to measure the time since the last upstream release that
has not yet been uploaded?

Alternativly, one could measure the time since the last merge request or
patch that has not yet been incorporated into an upload.

Kind regards
Christian Buhtz

Hi,

Le 5 juin 2026 14:30:35 GMT+02:00, Andreas Tille <tille@debian.org> a écrit :

how would that be different from the existing package salvaging procedure already documented at [1][2] ?


[1] <https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging>
[2] <https://wiki.debian.org/PackageSalvaging>


Happy hacking,
--
Aurélien

As a preface, I think the Cc list on these emails is horrible but I'm sure
it's intentional so I'm not dropping anyone.

[...]

I still think that formally orphaning unmaintained but not formally
orphaned packages is the best
thing (when they can't/shouldn't be RMed) because it's the only thing that
explicitly marks a package as orphaned, i.e. that nobody cares about it.
Shoving them into Debian Commons is not better than shoving them into
random teams as was done before: it still hides their status, adds some
busywork and prevents them from being formally orphaned for some more
years.

*cough* I mean...

Don't we have a mechanism where a specific really existing person can become a
maintainer of an unmaintained but not formally orphaned package directly?

Are you asking about mass-orphaning via the MIA team or is there another
process I've forgot about?

Hello Aurélien,

Am 05.06.2026 15:25 schrieb Aurélien COUDERC:

Sometimes there are packages where "uploaders" jumping in, doing
the work and the DM only uploads the work of "uploaders" without much
more. Such cases are IMHO not covered by the current salvaging
process.

Best,
Christian

Quoting Aurélien COUDERC (2026-06-05 15:25:48)

As I understand it, salvaging is a process to adopt a package, whereas
this seems to be an interest in revoking a maintainer *without*
adoption.

 - Jonas

...so orphaning + a QA upload...

G'luck,
Peter

Salvaging requires someone to become the maintainer.

Such cases also are likely irrelevant (hard to be sure when one needs to
guess what do you mean by ""uploaders"" and "the DM").

There is no incomplete orphaning process, the package was not supposed
to be orphaned.

This bug (#879296) is a "remove from Uploaders"-type bug, it has been
filed as a result of an MIA process in 2017.

It only affects only one of the two uploaders recorded in d/control, so
orphaning the package was not warranted when I filed this bug.

Hi Andrey,

Am Fri, Jun 05, 2026 at 06:34:02PM +0500 schrieb Andrey Rakhmatullin:

The CC list involves all people who posted to the two open bugs (+ MIA
team).

I personally see a difference between the QA team and Debian Commons, but
even if we assume for the sake of discussion that moving the package to
the QA team would be preferable in this particular case, what process
would you suggest to formally orphan the package under the current
circumstances?

For clucene-core we have a maintainer who has not uploaded in nearly ten
years, contact attempts that went unanswered, repeated NMUs, and pending
fixes from contributors. Yet, as far as I understand, there is currently
no established procedure that would allow the package to become formally
orphaned without active involvement from the maintainer.

This is exactly the gap I am trying to discuss. If we believes that such
packages should become formally orphaned rather than move to Debian
Commons, what is the practical path to achieve that?

That would be ITS. Any volunteer(s)? I think most of the work needed for
the next upload is already done. However, even if somebody steps forward,
that would only solve the problem for this particular package.

BTW, we had a somewhat similar situation with libasyncns[1]. At the time,
the my mail received neither comments about how such situations should be
handled nor any volunteer willing to take over maintenance. I eventually
experimented with an "Intent to Orphan" process[2].

In hindsight, I agree that starting such a process without first seeking
consensus on the procedure was not a good idea. The criticism I received
on that point was fair.

However, that experience also reinforced my impression that we currently
lack a generally accepted process for dealing with packages that appear
to have no active maintenance but are not formally orphaned. In the case
of libasyncns, the package has since been adopted (#1123614), which is a
good outcome. My takeaway is not that the specific process I used should
be adopted, but that we would benefit from agreeing on some process for
handling such cases.

Without a shared procedure, we seem to be left with discussing individual
packages one by one, while contributors willing to help have no clear path
forward.

Kind regards
    Andreas.

[1] https://lists.debian.org/debian-devel/2025/06/msg00131.html
[2] https://bugs.debian.org/1107475#10

Sure.

Discussing a process to orphan someone else's packages (which, even to my
knowledge, was asked for multiple times as a better alternative to adhoc
processes such as ITS hijacking) would be better IMO but that's not what
you asked :)

My personal opinion is that it should be similar to ITS in principle but
with (much) tighter requirements for package eligibility and (not too
much) longer timelines for the process. And with a thicker skin for the
submitter.

(restoring the context) you said there are volunteers, that's why I
pointed to ITS. If there are no volunteers, that's a different matter than
what you said.

Hi

[No need to CC me, I already get this 3 times]

Small comment.


In my opinion, if you want to maintain it in Debian Commons, you are
salvaging the package and should use the salvation process. Debian
Commons is intended to declare weak ownership, which is something else
than no ownership. If you are willing to stick your name to a package in
uploaders at least, ITS should work for you already. If you don't, than
Debian Commons shouldn't be part of your solution.

Paul

Hi Paul,

Am Sat, Jun 06, 2026 at 11:06:40AM +0200 schrieb Paul Gevers:

Reduced the CC to relevant bugs + Maintainer + Uploader.

OK, you do not consider Debian Commons part of the solution, and I can
understand the argument that Debian Commons should only be used when at
least one person explicitly wants to take ongoing responsibility for the
package.

My reading of the current thread is that several people agree that
clucene-core appears to lack active maintenance, while there is less
agreement about the appropriate process to handle such packages. Since
the package does not seem to fit the usual MIA workflow, perhaps we
should discuss what criteria and procedure would be appropriate for
formal orphaning in such cases.


To solve this we need criteria for packages for which a formal orphaning
process may be initiated by a contributor and concluded by a QA upload.
I'd suggest the following criteria:

Mandatory criteria
------------------
  * No maintainer upload for at least 5 years.
  * At least two documented contact attempts over a period of at least 6
    months with no response from the maintainer
  * At least one non-trivial NMU has been required since the last
    maintainer upload (no mass transitions and similar archive-wide
    changes)
  * No indication from the maintainer that they still intend to maintain
    the package
  * A contributor is willing to prepare the QA upload and document the
    evidence.

Other indicators
----------------
These are not required but strengthen the case:

  * Repeated (non-mass) NMUs
  * RC bugs remaining unfixed for an extended period
  * Patches pending without maintainer response
  * Uploader(s) also unresponsive


If a package fulfills these criteria, I suggest the following process:

 1. File an Intent to Orphan bug documenting why the package satisfies
    the mandatory criteria.
 2. Make sure to CC Maintainer and Uploaders when filing the bug.
 3. Wait 21 days.
 4. Upload to DELAYED/15 *and* CC debian-devel list when informing
    Maintainer and Uploaders about the upload.
 5. Any response from the Maintainer or member of the Uploaders list
    indicating continued interest in the package immediately stops the
    process. Substantial objections raised on debian-devel should also
    result in cancellation of the upload until those objections have
    been addressed.

(Motivation for DELAYED/15 is that there might be additional input
from debian-devel with good reasons to cancel the upload.)

The intent is not to replace the MIA process, but to provide a path for
cases where contributors believe a package lacks active maintenance and
no MIA process has been initiated.

If there appears to be support for such a procedure, I will file an MR
against developers-reference to document it.

Kind regards
    Andreas.

* Andreas Tille <tille@debian.org> [260608 11:01]:

I do not understand why clucene-core "does not seem to fit the usual MIA
workflow", and I suspect that this is where others are also not
following your logic.

What I am reading from others in this thread is that the correct way
forward with this package is to start the MIA process with the remaining
uploader associated with this package.

You seem to be saying that there should be a way to orphan a package
without either involving the MIA team or getting the blessing of the
maintainer, and my question is "Why?"  If there is a maintainer or
uploader who is not MIA, then discuss with that person options such as
orphaning the package or moving it to Debian Commons or something else.
If not, then follow the MIA process.

If there are multiple maintainers, and none of them are responding to
both collective and individual pings, start the MIA process, letting the
MIA team know the specific package you are concerned about.

I think all of your "criteria" constitute unnecessary bureaucracy for a
problem that already has enough bureaucracy.

...Marvin

I feel like the answer is "I don't want to wait some more years".

I think this framing is useful. And think the answer is:

* In past several years the MIA team was reportedly nonexistent.
* When someone sees a package that has been clearly unmaintained for
   years, a normal desire is to mark it as orphaned "now-ish" and not "in a
   year or several".

It's replacing one kind of bureaucracy with another, simpler, one.

Maybe I should have asked what the intention of the plan here is in
the first place. It seemed to me that the subject was packages that,
to quote:

| appear to lack
| active maintenance, but where no formal orphaning has taken place

So either they need orphaning or salvaging.

I don't understand why we need yet another thing.

Chris

Then I don't see why this discussion exists in the first place.

Best,
Chris

We believe that the bug you reported is fixed in the latest version of
clucene-core, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 879296@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille <tille@debian.org> (supplier of updated clucene-core package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 05 Jun 2026 08:40:27 +0200
Source: clucene-core
Architecture: source
Version: 2.3.3.4+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Commons <clucene-core@packages.debian.org>
Changed-By: Andreas Tille <tille@debian.org>
Closes: 879296 1059805 1139752 1139802
Changes:
 clucene-core (2.3.3.4+dfsg-2) unstable; urgency=medium
 .
   * Team upload.
   * Migrate package to Debian Commons
     Closes: #879296, #1139752, #1139802
   * Secure URI in Homepage
   * Add watch file documenting that project is Untrackable
   * d/copyright: DEP5
   * debhelper-compat (= 13)
   * Add CLuceneConfig.cmake to devel package
   * Remove unused lintian-overrides
   * Apply LibreOffice patch to allow not writing random timestamps into
     generated files, making them unreproducible
     Closes: #1059805
   * Standards-Version: 4.7.4 (Removed Priority field)
Checksums-Sha1:
 a184ec39e79fbf64dce8affeb4093eafdb058098 2192 clucene-core_2.3.3.4+dfsg-2.dsc
 1fcf29e69b7918dcab9aee79b82cba4d94b51a58 12340 clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 c8203218fb5776b8f2fd3de5bc41358958f2e9dd 6890 clucene-core_2.3.3.4+dfsg-2_source.buildinfo
Checksums-Sha256:
 cec5d6b729ceaf2b835957ef5c52ff9562b0471ab888cc6af8f9a7ee86b560b0 2192 clucene-core_2.3.3.4+dfsg-2.dsc
 ac37f056368461fad4f86649b42d2ad65f73b41a81a39ef2cb39f3e7da87c7b7 12340 clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 ed43fa710f402af7abff6478f093fc61a3b6c27fd4eb840b582794ca400c132f 6890 clucene-core_2.3.3.4+dfsg-2_source.buildinfo
Files:
 f50c40ea5245347c0f551ac7b8546afa 2192 libs optional clucene-core_2.3.3.4+dfsg-2.dsc
 98c0b4d40ebafa287a11fa95ca4fb63a 12340 libs optional clucene-core_2.3.3.4+dfsg-2.debian.tar.xz
 1ef2c3eb5a777e359aaf2b2e6c2a1fe8 6890 libs optional clucene-core_2.3.3.4+dfsg-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE4S3qRnUGcM+pYIAdCqBFcdA+PnAFAmotKDMACgkQCqBFcdA+
PnBL4A//RHncYLz7dSfUv0ddOqkkfo+/OAJdRSPhMods/DWGbeeQn8V12oF745Ab
s6RfB/vbUz38FCk6YrqR0r8/4UV+82Z0RQ2HI96XhRAXHjo3wBDkZHetmmNOzP05
oE8ceL7kbuWv4Jm5iGqupEK3YQ1G32rB4JnC1Jop/AFUAbCS1ZFaiwwSENBNkRx6
5oqid85qMFrgXtIL4HEzdxVn8EwlYvsOy1wpZoheoGaCRKoik3kC9AgJVXvdlN6Y
W4FqYcvTx7hYeVUtGE1SGBX7bR8DMU4ULKB9hiXRcT0MXjgWeGScg/rIEwd9h4uX
MFkQvuwVDAzqvBeHFh9AH6AGB3C/biskaa2fVkqk9zsmVmHZT8hyMXV55KkGNNzi
sxKB2YCHMyDscRZPFYL+ZDDx4bACt1lYCfXFHCA9nJl7q4OvMEbKVbvUBKlxWiXt
rjVY9OZUoYwRDDL5bDEVAq4qgy7XWCNp7A5zjDe3TfQMxO2u2ySi4yjQ7MA9Px5A
hSrytjRQDJbxU3/bhE9hy1QvmA/N2eyerUEcAfT64J9FSeaDyNT0J3ku2DojIa+h
9VaAWxc91E4pYj/c9n4zvYXssaxPzqTx2msicDgUr4EJ25J82zir6EMUL/GuZrGy
wz3cNoxvcJDL+6RjP1mg+yFxahwYxQ+hIiM9e0rHzH31lP0pf+I=
=lM+6
-----END PGP SIGNATURE-----