Re: Semi-serious proposal: drop all optional entries from comps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

It should be possible to turn those checks into CI hooks.
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?

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.

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?

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux