On 7/2/22 03:58, Larry Finger wrote:
On 7/1/22 10:46, Dominique Leuenberger / DimStar wrote:
Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build
This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care'
Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available'
Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200)
As my daughters would say "OMG, has it been 8 years already!" Unfortunately, I had been in this game a little longer than that. By the way, congratulations on doing a great job!!
As the maintainer of a complicated package (VirtualBox) that frequently fails to build in its 3 homes of TW, Leap 15.3, and Leap 15.4, I get E-mails every time there is a build failure. If a maintainer ignores those warnings, or there is no active maintainer, then you can end up in the situation that nextcloud-desktop is in.
Finally, as a maintainer nearing EOL (I'm 82), I implore people to become maintainers, particularly if you have a vested interest in a particular package. These things do not fix themselves, and bitrot is real.
Is there a list of packages that need active maintainers other than Dimstar's "fails to build list?" If not, there should be.
In Theory such a list would be really nice, but in reality some people know that they no longer have time and post a list of packages up for adoption to this list which would be the best starting point for such a list. In many other cases maintainers slowly drift a way or something else happens meaning they no longer have time and simply don't get to sending such an email. The only way we can really detect these cases is when a package stops building or a security but is raised and not dealt with in a timely manner. Using activity doesn't really work because for example I have some serial port related packages that haven't changed in 8 years because serial ports havn't changed and the packages just work. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B