Re: Commit fest queue

"Bruce Momjian" <bruce(at)momjian(dot)us> writes:

>> I still think it would be best if the patch authors did the work. They
>> are the ones who care about the patch and want the review, and they're
>> in the best position to know what the status of a patch is. Others can
>> do it as well of course, in the spirit of a Wiki.
>
> Does that move us in the direction of the patch tracker? That does
> raise the bar for patch submitters, though I would catch any patches
> that weren't in the tracker.

Not really, whatever tool it's in the hard part is reading the emails and
deciding what to do with them.

What would move us in the direction of this mythical "patch tracker" would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.

That's the whole point of a special purpose tool for things like this,
enforcing that all the ts are crossed, is dotted, and all procedures followed.
Eg, requiring that the "Patch status" field be filled in or that two reviewers
don't grab the same patch.

What a request tracker does *not* do is magically make decisions for us. We
still have to review the patches, we still have to make technical decisions.
Patches which are too hard to wrap our head around would still sit there until
someone stands up and applies or rejects it. (Anyone who's reported a Mozilla
bug in the past 8 years might know what such a tracker looks like...)

Frankly until we decide what our workflow is and what information we want to
track I don't see why -- or even how -- we would pick a tool to track it.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!