On 05/02/2017 04:03 PM, Jason L Tibbitts III wrote: >>>>>> "AB" == Aurelien Bompard <abompard@xxxxxxxxxxxxxxxxx> writes: > > AB> My questions are: should we drop it? Rework it? How high a priority > AB> is it really? > > Well, I think we would really use... something. The current bugzilla > based "experience" is basically a mess we've all learned to work around > (or given up on) and I still feel bad for new contributors who have to > struggle with it. But really, the whole process needs an overhaul and > something that simply codifies the existing process probably isn't the > best way to spend your free time. Agreed on all points. > A workflow built around pagure and various other pieces of > infrastructure like copr and taskotron which could give some measure of > automatic builds and error checking would be incredibly great but I have > no idea how possible it is. I think it could be quite possible, and might be more doable once we have the pagure pkgs frontend in place, etc. > Then we'd just say "package submissions go into this namespace in pagure > and get hooked up to automated builds and tests and whatnot". Add a way > for prospective reviewers to see those submissions and some mechanism > for a reviewer (with privileges) to approve a package for inclusion. > Then it's just a simple matter of figuring out how to get the approved > package into the distribution. > > But again, I have no idea if any of this is actually possible. I do > know I'd be able to do a heck of a lot more reviewing work than I do now > (which is basically zero) if I could so things like: > > * Click through a pagure listing that shows me just the package which > are actually building and ready for review > > * See everything right there, including a spec file, current rpmlint > output and things like taskotron checks > > * Make quick comments on the spec file > > * Star a repo so it shows up in the list of packages I did review work > on (so I don't forget) > > And a whole lot of that seems to be a mashup of what pagure and copr > already seem to do. Anything that encourages drive-by reviewing and > incremental improvement of submitted packages while hiding packages > which aren't at the point of building properly is a huge plus in my > opinion. Yeah. Part of this sounds like it could just be a PR against a new pagure "New Package" or something, which could get you spec and comments and jenkins builds, but likely is still missing things, but I wonder if we couldn't get something that wasn't any worse than bugzilla this way. ie: * Get pagure in front of pkgs. * create a new namespace (they are all the rage these days right? :) called 'proposed packages' or something with only a rawhide branch) * Have a special pagure project called 'proposed packages' for tracking things. * User submits PR with spec+patches * have some small gate here where someone acks a proposed spec (for legal, etc). * The PR is committed, builds in koji, then taskotron runs checks on it, jenkins runs checks on the spec+patches. * Reviewer checks those things, adds comments/problems, submittor fixes them. * Finally Reviewer acks PR and it gets added to normal rpms namespace (with git history). * proposed-package version is closed/retired in favor of the new one. This might get us somewhere leveraging pagure and jenkins and taskotron. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
