[rekonq] Fwd: [ANNOUNCE] rekonq 0.6 stable release

[Benjamin Poulain]

On 09/15/2010 05:11 PM, ext andrea diamantini wrote:
> I think something has to be done, yes. Are you suggesting something you
> just use (eg: in Qt, QtWebKit)?

Qt and WebKit uses different tools for review. I'll explain both since 
they are both interesting for their own use cases.


For QtWebKit, most of the patches are posted along with a bug report. 
The patches are reviewed by official reviewers, and they give the 
go/no-go for the patch to be integrated. Once the patch as been reviewed 
positively, one can push the patch manually to the repository, or let 
the bots do the integration.
Here is an example of a hairy review for WebKit: 
https://bugs.webkit.org/show_bug.cgi?id=33150

For WebKit, it is mandatory for each patch to be reviewed. The reviewers 
also insist on having tests with the patches, so the test coverage just 
grew huge over the years.
The main problem with WebKit is the time between the patch writing and 
the integration. This model is only sustainable because WebKit is so big 
and there are so many people working on it.


For Qt, we have two types of review. The formal reviews on 
Gitorious.org, exactly like for Rekonq. This is the way external 
contributors add code into Qt.
For "trusted" developers (Nokia employees of the Qt organization), we 
simply do the reviews on IRC (publicly, on the channel #qt-labs).
e.g.:
<benjaminp> sroedal: Thiago seems to be away, could you review this?: 
http://pastebin.com/TzJkUtXv
<sroedal> benjaminp: looking
<sroedal> benjaminp: as long as the assertion that memory is aligned on 
16-byte boundaries is correct (which sounds reasonable) r=me :)
<sroedal> benjaminp: wouldn't the possibility to load bytes before the 
image data anyways be there if src image width was <= 2 pixels?
etc

> There are also a bunch of "orthogonal" problems (are they really?) about
> I'd like to consider:
> 1) the imminent move (November, 2010) to a new platform (git.kde.org
> <http://git.kde.org>).
> 2) Maintain the lowest possible entering barriers. It seems that git +
> gitorious merge requests system are the best tool for. IMHO it's not the
> same in the actual KDE reviewboard. But I hope it is so just because of
> SVN...
> 3) The necessity to maintain a sort of control on the introduction of
> new features.

I think Rekonq could use the flexibility we have for Qt. Patches by 
occasional contributors can continue to go to Gitorious. Patches that 
are committed directly by regular developers could simply get a review 
with a pastebin+IRC or any reviewboard.

The need is really to have someone else understand the code, and trust 
the patch enough that you can put his name on it as a reviewer.

cheers,
Benjamin