Re: [HACKERS] commitfest management webapp
От | Greg Smith |
---|---|
Тема | Re: [HACKERS] commitfest management webapp |
Дата | |
Msg-id | alpine.GSO.2.01.0905262135350.7909@westnet.com обсуждение исходный текст |
Ответ на | commitfest management webapp (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] commitfest management webapp
|
Список | pgsql-www |
On Tue, 26 May 2009, Robert Haas wrote: > I'm open to suggestions on how to improve this situation, though, > because it's definitely not ideal, and precludes things that reasonable > people might want to do, like "contact the guy who submitted this > patch", "contact the authors of all patches waiting for review", and > similar. Since you're taking the message-id where the patch was submitted at as an input, couldn't you scrape this information out of the archives? You probably want to do a bit of that regardless; having the program pull and display the author and subject line of the archived message is a good sanity check that you entered the message ID correctly. > I know that there are some of you reading this who may think that we > should convert to reviewboard or patchwork or some other system. I can > say that personally I'm unimpressed by those suggestions because they > will almost certainly require process changes that this does not We used Reviewboard a fair amount here at Truviso for a while. Lately a good chunk of that patch review has been happening more efficiently by passing pointers to private git branches around instead. I think you're right to focus on just the review workflow and not the patch review itself, let people use whatever tools they're already comfortable with for that part. I just spent a few minutes poking around your code and that quickly was able to see how things fit together, which is certainly not something I can say about Reviewboard etc. The interface looks good and the code easy enough to improve. The main concerns I'm left with after that review are with how to properly test the security of the code. Some maturity there is one major thing that more packages in larger use have going for them vs. rolling your own in this sort of situation. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-www по дате отправления: