[rekonq] Fwd: [ANNOUNCE] rekonq 0.6 stable release
Benjamin Poulain
benjamin.poulain at nokia.com
Thu Sep 16 12:48:14 CEST 2010
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
More information about the rekonq
mailing list