I'll apologize in advance for rambling, but I've been kicking around ideas in this space for very many years now. >>>>> "SJS" == Stephen John Smoogen <smooge@xxxxxxxxx> writes: SJS> Well it is quite clear we are doing something wrong and have been SJS> for as long as the project has been going on. It's true that we've basically always had a backlog of tickets. To be fair, it's not as bad now as it was at its worst. I haven't looked at the queue in a couple of years and while there are some familiar tickets there (one is now over 14 years old) I see pretty much what I expect. SJS> Package reviews are like dirty dishes and laundry to a lot of SJS> people and there are always something they would rather do or HAVE SJS> to than do it. Until someone removes the Somebody Else's Problem SJS> Field from it.. reviews will pile up. Yes, but there are other factors. For example, we almost never just say "no", instead letting the tickets just sit there. We must at some point accept the fact that there are going to be pieces of software that basically nobody cares about, and not say that absolutely everything has to be part of the distribution proper. Sometimes I wish we could separate out the different "domains" of package acceptance and let different people (or even automated systems) handle them. For example, here's a dumb list: 1) Is the thing legally acceptable? 2) Does the thing build? 3) Does the package meet some minimal standard (installs without dependency problems, doesn't obsolete glibc, doesn't drop junk all over the filesystem, etc.) 4) Is the payload fit for purpose (software needs to run, content needs to... be contenty, etc.)? 5) Is the packaging itself (specfile) maintainable (meets guidelines, etc.)? If a script could drive by and say "yep, it still builds" every so often, that would actually help quite a bit. If someone could drive by and say "yep, the license stuff checks out" then that would free a reviewer from having to do that. (And back when I did reviews, I spent a significant amount of time worrying about that.) If I could run through, look at specfiles and red flag things which are problematic without having to sign on to the entire process (wait for builds, worry about licensing) then I might occasionally spend some time doing that. I wonder if it would be possible for review tickets to acquire a number of flags instead of just the one fedora-review flag, and the package would simply be acceptable when all of the flags are checked off. And on a separate tack, I would love to see an alternate path to package acceptance that goes through COPR. So if a package (or stack of packages) is functional and well-maintained in COPR, someone with appropriate privileges could simply nominate it for inclusion in the main repository. Other folks could look, have a chance to comment, and then if sufficient positive votes are collected, the repo is created. I can see that being really incredibly useful for stacks of packages (where the one desired packages has a whole tree of dependencies that have to go in first). Not only do these clog up the review queue and make the situation look even more hopeless, but there are so many round trips through the process that it's just incredibly painful. And while I'm on a roll, is there any system at all that we could use where I can look at a specfile and make comments on specific lines? I can do that in a PR in any forge; can we leverage that way of working somehow? Is there any crazy way that we could have new package submissions be submitted as PRs against some base prototype package repo, with the existing koji CI stuff automatically making sure that the submission builds? - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
