On 05/02/2017 04:03 PM, Jason L Tibbitts III wrote:
>>>>> "AB" == Aurelien Bompard
<abompard(a)fedoraproject.org> 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