State of the Review Server (Fresque)

[Aurelien Bompard]

Hey people,

Around 2 years ago, we (Pingou, Rahul, Vivek and me) started designing
and writing some code for Fresque, a package review server for Fedora.
The aim was to replace our current Bugzilla-based process.
However, stuff happened in the meantime that were higher priority and
Fresque development stopped around last year. It's a Flask app with
about a hundred commit, so it's in pretty early stages :
https://github.com/fedora-infra/fresque/

My questions are: should we drop it? Rework it? How high a priority is
it really? With the switch to Pagure for dist-git, I suspect that the
design will have to change anyway.
I know it isn't high on my priority list, and I wouldn't mind dropping
it, since I feel like both the design and the implementation would
need significant work (implementation-wise, the React experience we
now have with Hubs would be very useful there).

What do you think ?

Aurélien

[Jason L Tibbitts III]

> >>>> "AB" == Aurelien Bompard
> <abompard(a)fedoraproject.org&gt; 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.

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.

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.

 - J<

[Kevin Fenzi]

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