Group projects with simultaneous releases

[AMDmi3]

Ah sorry, the page that lists per maintainer which packages they maintain are outdated.

Unusable is not really "unusable", but the list is just filled with KDE Release service applications, even though I need to know for just one if it's outdated or not to know for them all they're outdated. I can still use the list of course, but it takes lots of going through pages to find non-KDE packages that I have to do something for.

_Originally posted by @PureTryOut in repology/repology-rs#104

[AMDmi3]

I can't really imagine changing the projects list behavior for this case, as it would imply hiding projects, e.g. not showing outdated projects in an outdated projects list, which is POLA violation.

It can be improved the other way around though, by adding more filtering options (related #88), e.g. excluding specific categories (it relies on whether there's some repository which assigns categories consistently).

Adding some special behavior seem to be more useful for feeds though, which are easily spammed in this case, and unlike the projects list would not be hurt by replacing a lot of similar entires by e.g. "kajongg and 8 more projects in category KDE".

Still, I don't see a way to implement this reliably as

• it needs groups defined which depends on either using categories from some repository (unreliable, uncontrolled, unsynchronized and requires reliance on a single repo) or defining categories in repology (requires manual maintenance which we strive to avoid)
• it's still broken if packages are updated non-atomically, which would prevent grouping them in time. It already visible on the history link above as packaged were updated in at least 9 packs (would be more of them if we support more frequent updates).

Summarizing, I don't see a way to implement any specific behavior for this case reliably and in fact I don't see this case much different than a large bunch of unrelated updates.