Re: Tracking patch pings

["Carlos O'Donell" <carlos at redhat dot com>]

On 05/15/2013 05:20 PM, Joseph S. Myers wrote:
> To raise more visibly something I mentioned in another thread:
> 
> Should we have some system for tracking patches that are pending review, 
> especially those that have been pinged?  For example, there could be a 
> list on the wiki page for the current release cycle of patches believed to 
> be ready for review and the contribution checklist could say to add your 
> patch there when pinging it.  (Ideally we'd have people who specifically 
> try to keep a lookout for unreviewed patches and add them to the list 
> after a week even if not pinged.)
 
What problem are we trying to solve?
* Keeping track of patches that need review as a release approaches?
* Make such review as light-weight as possible?

Is using bugzilla too heavy-weight?

Is using the wiki too unstructured?

What benefit do people see in patchwork over an unstructured
wiki list and heavily structured feature bug?

Lately my opinion has begun to lean towards the fact that bugzilla,
the wiki, and patchwork all lack critical integration with git which
is required to make the workflow easier.

Other people think the same thing or gerrit wouldn't exist.

For a quick introduction to gerrit:
https://review.typo3.org/Documentation/intro-quick.html

I like the way gerrit works.

(a) User pushes end up in gerrit pending repo.
(b) Reviewers review patches in gerrit, and if you get consensus
    it gets checked into the master repo.

Gerrit always knows the list of patches that need review by
virtue of the fact that those patches are tracked as commits
in the pending repo.

A patch that needs review, and got it, would get checked in
right away. There is no intermediate state of patch checked
in but tracker not updated.

Are there things we would have to fix? Yes, NEWS, and ChangeLog
probably need special treatment for merging, or we just have
to change the way we work to make life easier :-)

Cheers,
Carlos.