On Mon, 2018-09-24 at 08:26 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Sep 23, 2018 at 10:41:31AM +0200, Nicolas Mailhot wrote: > > Le samedi 22 septembre 2018 à 11:38 -0700, Adam Williamson a écrit : > > > But at the same time I think Matt's right that comps -at least as it's > > > currently set up - is kind of a really *bad* way of doing this, and > > > that seems fairly well demonstrated by the problem I'm trying to solve > > > - that comps has tons of broken entries in it. Just from looking > > > through the file as I do this, I really suspect that no-one is > > > maintaining quite a lot of the groups and the packages in them may > > > well just not make much sense any more. > > > > That's a QA problem > > > > But really, the problem is not the comps format, it's that any kind of > > classification activity is both tedious and optional (if you know how to > > classify a package you do not need the classification in the first > > place), rots fast in presence of high package churn, and can only work > > long term with lots of janitorial involvement (both human and > > automated). > > That was my first thought too. > > On Fri, Sep 21, 2018 at 06:14:51PM -0700, Adam Williamson wrote: > > I am currently working on finding and removing all comps entries that > > point to packages which don't exist any more. > > > > While doing this extremely tedious task [...] > > I would love to see some more info before any decisions are made. > I *thought* I more-or-less understand the comps process, I remember > doing some minor changes in the past, but things seem to have changed. > > How are you doing those checks? Is it > https://pagure.io/fedora-comps/pull-request/328?
Yes. > It should be possible to turn those checks into CI hooks. Eh...it'd need a less janky script. That one is pretty dumb. Besides, there's an obvious problem with that idea: missing packages don't usually show up in the list via comps PRs. It's not that people make changes to comps that list packages which don't exist *right then* - not usually, anyway. What happens is packages get retired or renamed, and no-one remembers to update comps. If we want to fix that we'd need to somehow run the comps script on all changes in dist-git and block those changes on introducing comps problems, which seems like a rather more difficult problem. > There was some jenkins jobs being run on PRs in > pagure.io/fedora-comps, but it seems to have atrophied and > doesn't appear on new PRs. Do we have any automated checks for comps now? I don't think so. > Instead of designing a whole new system that needs to be > a) designed, b) agreed, c) documented, d) implemented, e) integrated > with all the other tools, and f) referenced in all the docs where > the old system is now referenced, > why not first fix the CI to do the checks? Pruning nonexistent packages > really sounds like something that can automatized. Well, it's not quite as simple as it sounds to do it correctly, in fact - it took me about five hours to handle the first 40 or so bad entries, because I didn't just unthinkingly chop out all the entries. I actually looked at each package's dist-git history and sometimes upstream history to figure out why it had been retired, whether it had been directly replaced by something else, or if there was in some other way a clear replacement for it. Besides, the reason we're now kicking around the possibility of replacing/improving the system itself is that this isn't the *only* problem with it. > Another question: people keep mentioning unexpected breakage from > changes by random contributors. But https://pagure.io/fedora-comps/ > seems *very* tightly controlled with write access by only @releng and > adamw. So is this still actually a problem? Not much (though it can sometimes be hard to completely predict the impact of all proposals). But it *used* to be, which is why we have the tight access control. Adding the tight access control, though - as KK correctly pointed out - has the negative effect of making it perhaps too *hard* to make changes that will always be trivial in impact, like adding/removing 'optional' entries to/from a group mainly intended for display in package managers. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
