Hi,
I put an idea on the wiki that I think would be a good SoC project: a web app for the review process. I put some ideas here:
http://fedoraproject.org/wiki/FedoraBounties#head-ed0e64b4a58f80c721d31f17a0...
Andrew
On Wed, 2007-03-21 at 20:14 -0400, Andrew Overholt wrote:
Hi,
I put an idea on the wiki that I think would be a good SoC project: a web app for the review process. I put some ideas here:
http://fedoraproject.org/wiki/FedoraBounties#head-ed0e64b4a58f80c721d31f17a0...
We need to think about that before implementing. We definitely need to share the responsibility for mentoring such a project between some Fedora Packagers and Fedora Infrastructure people. The Packagers will know how the current system fails and a new system could improve things. Infrastructure will know about the different systems we have to tie into/replace:: PackageDB, Bugzilla, Koji-buildsys, Account system.
Trying to do the whole thing as a SoC project is, I think, overzealous. I'd like to see a definition of what we want to achieve and what existing systems it will tie into. Then break the problem down into a few pieces and allow SoC to handle any of those pieces. That way, we don't end up with a working web app that doesn't interoperate with the rest of our infrastructure.
-Toshio
* Toshio Kuratomi a.badger@gmail.com [2007-03-21 20:38]:
Trying to do the whole thing as a SoC project is, I think, overzealous. I'd like to see a definition of what we want to achieve and what existing systems it will tie into.
I was envisioning just the review process itself for a SoC project.
Andrew
On Thu, 2007-03-22 at 13:36 -0400, Andrew Overholt wrote:
- Toshio Kuratomi a.badger@gmail.com [2007-03-21 20:38]:
Trying to do the whole thing as a SoC project is, I think, overzealous. I'd like to see a definition of what we want to achieve and what existing systems it will tie into.
I was envisioning just the review process itself for a SoC project.
Yah. My point is that this ties into a lot of other projects, some finished and some ongoing. What are the goals of the web app? To move away from bugzilla? Which features in particular are not meeting our needs on bugzilla and which does bugzilla do well? What do we want to do with the data from reviews? If we tie this into preapproval builds, do we have to do reviews of untrusted packages before submitting to mock or is mock sufficiently secure to do a build up front?
Work done on moinmoin, or backup software in previous iterations of the SoC were largely independent of what we do with the rest of Fedora. A Review Web App sits squarely in the middle of it. The mentor for this project needs to be aware of where they want the application to connect to other Fedora services and how it's supposed to improve on the current experience.
Which is not to discourage you from pushing this as a project. Bugzilla has shortcomings as a reviewing location. But there's more to this than a better UI. Defining what the app needs to solve will allow for defining what a successful project will look like rather than sticking some poor student in the middle of a bunch of competing interests with no clear idea of what they need to do to create some software that we'll be able to start using when they're done.
-Toshio
Hi,
On Thu, 2007-22-03 at 15:35 -0700, Toshio Kuratomi wrote:
What are the goals of the [review] web app? To move away from bugzilla? Which features in particular are not meeting our needs on bugzilla and which does bugzilla do well? What do we want to do with the data from reviews? If we tie this into preapproval builds, do we have to do reviews of untrusted packages before submitting to mock or is mock sufficiently secure to do a build up front?
These are good questions. I think in my opinion the problems with the review process boil down to:
. review requirements spread out over multiple wiki pages . review requirements that are changing . workflow involves too many different websites and bugs
I'd love to see a tool that allowed people to upload an SRPM directly and then put it somewhere accessible to others (including the reviewer). We could automate a lot of the rpmlint and build checking as well. Then the requirements that we can't automate can be pulled live and presented to the reviewer in a side-by-side web app with checkboxes and comment fields. Something like the Mondrian code review tool developed at Google [1].
Sorry I didn't get back sooner as I realize this won't make this year's SoC. I'd still like to think about it as it'd be a great project for a Fedora contributor.
Andrew
[1] http://video.google.com/videoplay?docid=-8502904076440714866
-
Andrew Overholt -
Toshio Kuratomi