[webkit-dev] to reitveld or not to reitveld

Darren VanBuren onekopaka at gmail.com
Fri Jun 5 21:13:40 PDT 2009


I agree that using RPC is inefficient, and that we don't want to make  
the review process any more of a pain. We could also try writing our  
own code review software specifically designed to work with Bugzilla,  
so that we could run directly in the Bugzilla environment, and we  
could modify and retrieve bugs without throwing stuff around RPC  
channels, just by running some calls in the Bugzilla modules.

Darren VanBuren
onekopaka at gmail.com
====================
http://oks.tumblr.com/

On Jun 5, 2009, at 8:48 PM, Mark Rowe wrote:

>
> On 2009-06-05, at 19:02, Darren VanBuren wrote:
>
>> Surprisingly, the bug isn't a duplicate, or if there is a dupe, it  
>> isn't filed correctly.
>>
>> But I agree that any code review tool should be integrated with  
>> bugs.webkit.org, otherwise there would be a huge disorganized mess  
>> and it wouldn't be any better.
>>
>> Bugzilla wouldn't be hard to extend for this purpose, just adding a  
>> field for review status and then making whatever code review tool  
>> you chose update Bugzilla solves (b).
>>
>> Some modifications in the tool could also make it attach the  
>> patches to a bug, and you could also update any field in the bug.
>>
>> I mean, retiveld seems like a wonderful tool, it seems like  
>> something that would extend Bugzilla quite nicely. Pushing data to  
>> Bugzilla can simply be done with XML-RPC according to this page on  
>> bugzilla.org: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Server/XMLRPC.html 
>>  and there's plenty of XML libraries for Python you could use to  
>> work over XML-RPC.
>
> I don't think that duplicating data in two systems and pushing it  
> back and forth via an RPC mechanism is what Dave had in mind when he  
> was speaking of tight integration.  We need to *streamline* the  
> process of uploading and reviewing a patch, and having two different  
> ways to do this seems like a large step in the opposite direction.
>
> - Mark
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090605/2f3dc526/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090605/2f3dc526/attachment-0001.bin>


More information about the webkit-dev mailing list