## Gobby/IRC ## gobby infinote://gobby.debian.org/debconf17/bof/if_you_love_a_package_let_it_go IRC #debconf17-woody # If you love a package let it go 𝄞 ♫ Let it go………………………, let it go……………………… Can't hold it back anymore Let it go, let it go Turn away and slam the door I don't care what they're going to say Let the storm rage on. The cold never bothered me anyway ♩ ♪ ♫ ♬ free free set them free At this DebConf a few of us have been discussing the problem of packages that are not well maintained (or at least perceived that way), but whose maintainers are otherwise active in Debian. In this BoF we’d like to continue that discussion and hear about different people’s points of view. A great outcome would be some kind of concensus on a process or criteria to change maintainers for such undermaintained packages. # Problem The problem is that in Debian there are quite a few packages that a severe outdated, often new upstream releases waiting since ages, bugs on the BTS unfixed, often with patches... When the maintainer is clearly MIA, we have a process for it; we're kind of cool here. (even if that process currently takes long) But if the maintainer or the team is only partially acting, meaning that some packages are not touched for significant time, this gets complicated. Technically they are not MIA, so the MIA processes do not apply. We cannot do more than a nice gentle ping and plea if they could fix the situation. (which works quite often, but not always.) If someone shows up asking about a package, maybe even wanting to adopt it, we have to tell them that we cannot help and (only) if there are problems in the package that needs fixing ask them to consider NMUing them... (But NMUing new upstream versions is especially hard) Serial NMUs are not ideal either. Decreasing the NMU threshold is somehow easy, but packages maintained only by NMU are potentially blocking new maintainers. Another relatively common issue, but perhaps harmless: maintainers who take on co-maintainers (yay!) but essentially stop participating in maintenance (boo!). # Defintion of non-maintained Currently there is also no sharp definition when a package is "unmaintained". I've (tobi) talked already in Cape Town with a few people, and the outcome was that maybe some metrics could help here to define "unmaintained" and to define what can/should be done with unmaintained packages. # Ideas - Try to find a metric based definition when a package is unmaintained - this metric could maybe used to allow a new contributor to officially obtain maintainer status. ("free to adopt") - maybe involving the MIA team (might need some empowerment for the MIA team). As some people reply to MIA pings with promises to fix thing but failing to act afterwards. - base MIA process more/also on packages - encourage people to orphan packages - some auto-orphaning process like auto-removals - calculate "contributors" to a package according to VCS/changelog etc, and publicise on tracker. This might be related to metrics # Ideas on flagging issues Some ideas that came out of the discussion for the definition - there were no uploads by the maintainer in (several) release cycle(s), - despite package had severe problems, - new upstream versions available - bugs with patches, unanswered in the BTS - many standards versions and/or compat levels behind - only NMUs in a time period (again measured in release cycles?), unincorporated in the package - unanswered bugs in the BTS... - the package missed the last release due to RC bugs - **unanswered** wishlist "new upstream version" bug that has been open for long and debian's version is far behind upstream, can be retitled to "version in debian is obsolete" and marked RC, so that autoremoval from testing can happen - can require to make a cause for obsolescence instead of just a personal preference. Examples: "version in debian (testing) is not supported upstream anymore, and there is a new stable version upstream that is supported", "upstream is not providing security fixes for this version", "this version is blocking new stable versions of reverse dependencies from making it in debian" - if there are reasons to have an obsolete version in debian (new stable release breaks APIs many other packages depend on, and Debian maintainer commits to support the Debian version) then one can document so in the BTS, lower severity, tag wontfix, and do the usual things we do with the BTS - document a guideline for filing/retitling a RC bug saying that a package is obsolete # Questions - What would it need to empower the MIA team (came up in internal MIA discussion) - If metrics is an option, how to implement them. Kind of point based? Other? - should the hypothetical orphaning be triggered by request (e.g. by person wanting to adopt a package), or automatically? - Is it a big problem if we dramatically increase the number of orphaned packages? - should popcon weigh in this process - is removing unmaintained packages in scope for this discussion? - is this really MIA team's problem? It could also be seen as QA team more generally,rather than just MIA QA orphaning? - Or should determined unmaintained packages just be grabbable for everyone? (tracker could display this option?) # Misc - be careful with popcon stats # Next steps - ways to deprecating packages (in favour of newer software, obvious replacments) - how to inform the users - how to document alternatives raise DeprecationWarning("this will disappear in version {ver}, use {pkg} instead") - Removal vs Orphaning -- something makes more sense to really let it go? - QA Orphaning / Low Threshold Orphaning - weak maintainership - Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal thread starting at: - enrico brought up the "Several NMUs in a row -- then do an NMU just changing the maintainer to yourself". - steps to drive this according to enrico: - write it down - send to leader, dam, ftp-master -- would you block someone doing this? - announce to d-d-a - add to dev-ref BREMNER WILL DRIVE THIS -- consensus exists so shouldn't be too hard