Hi Lucas, Am Mon, Jun 08, 2026 at 08:25:02PM +0200 schrieb Lucas Nussbaum: > > 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. > > I find it a bit frightening that you disagree on the scope of Debian > Commons, and processes around it. Maybe it's a good indicator that it > should be specified more before building more stuff on top of it.
I think the issue is less a disagreement about the original scope of Debian Commons and more that I am exploring whether it could also help with a different problem. If I understood Paul correctly, the original idea was primarily about making it easier to express that a package is open to contributions from anybody interested in helping. In that model, Debian Commons serves as the maintaining team, contributors can upload without the social overhead traditionally associated with NMUs, and the people who care about the package add themselves as Uploaders. My understanding is that this process is initiated by somebody who is already taking responsibility for the package and intentionally moves it into that maintenance model. The clucene-core example is different. Here the problem is not that contributors are discouraged from helping, but that there appears to be no active maintainer involvement despite repeated attempts to move the package forward. The question I am trying to raise is whether a model such as Debian Commons could also help in situations where the existing maintenance structure has effectively become inactive. > I think that the current discussion could be expressed in terms of > states and transitions. > We used to have two states: > (M) "packages with, officially, a maintainer", > and (O) "orphaned packages". > > We have a process for (O)->(M) (adoption), two processes for > (M)->(O) depending on who initiates it (orphaning if maintainer, > forced-orphaning by MIA team), and a process for (M)->(M') (salvaging). > > Now we have an additional state, (W) "package with weak ownership in > Debian Commons". I think that it would be useful to identify the > processes for: > (O)->(W): adoption? but is that really adoption? > (W)->(O): salvaging? who is authoritative otherwise? > (M)->(W) by the maintainer: obvious > (M)->(W) by someone else: focus of this discussion > (W)->(M): who is authoritative to decide that one can take strong > ownership of a package that was previsously weakly-owned by many? > > Note that described like that, (M)->(W) can be achieved by > (M)--[salvaging]-->(M')-->(W). That it, using the salvaging process, > someone could take over ownership and then decide to turn it into weak > ownership. > > But still, I think that other transitions should be specified... I think this is a very useful way to look at the problem. However, I also think we are discussing two related but distinct questions, which is why I changed the subject line. The original question I wanted to raise was about the transition from a package that appears to lack active maintenance into some form of Debian Commons maintenance. In your notation, this is primarily about defining an appropriate process for (M)->(W) when the current maintainer is not actively participating, and more generally about whether we need an additional process alongside orphaning and salvaging for such situations. Your mail raises a broader and equally important question: once we introduce the state (W), what are all the valid transitions into and out of that state, and who has the authority to initiate them? I agree that these transitions should be specified and your state-machine description is a helpful framework for that discussion. To me these are related but separate topics. My original motivation was the first one: how do we deal with packages that appear to have fallen into a maintenance vacuum? Once we decide that Debian Commons can be part of the answer, your questions about the complete set of state transitions become highly relevant as well. Thanks a lot for your analysis in any case Andreas. -- https://fam-tille.de
