[webkit-dev] to reitveld or not to reitveld

[John Abd-El-Malek]

On Mon, Jun 8, 2009 at 5:15 PM, Eric Seidel <macdome at gmail.com> wrote:

> At least one person has tried to tie review-board with bugzilla:
>
> http://www.visophyte.org/blog/2009/03/20/using-review-board-for-bugzilla-request-queues-reviews/
>
> I expect that we'd have to hack review board to do bugzilla-based
> authentication.  (Just like we'd have to hack rietveld to not run on
> AppEngine if we used it.)
>
>
> I agree with others that the rietveld authentication being tied to
> AppEngine and thus Google accounts is a show-stopper for WebKit.  I
> have no interest in creating yet another account and then worrying
> about whether I'm correclty logged into both bugzilla and webkit.org's
> google account in order to do patch reviews.  Currently I avoid
> dealing with chromium's tracker/review tool because every time I do I
> have to log out of my gmail.com google account so that I can log into
> my chromium.org google account. :(


AppEngine apps don't have to use Google Accounts for authentication.
 Rietveld has its own user-account layer, so it's possible to plug-in
different forms of authentication.


>
>
> -eric
>
> On Sat, Jun 6, 2009 at 7:44 PM, Ojan Vafai<ojan at chromium.org> wrote:
> > On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe <mrowe at apple.com> wrote:
> >>
> >> On 2009-06-06, at 15:02, Peter Kasting wrote:
> >>
> >> On Sat, Jun 6, 2009 at 1:48 AM, Mark Rowe <mrowe at apple.com> wrote:
> >>>
> >>> Of the issues that Ojan mentioned in his original email, I see three
> that
> >>> would need to be addressed before we could consider adopting Rietveld:
> >>>
> >>> - Currently tied to AppEngine.
> >>
> >> I don't understand why this is problematic in the least, any more than
> >> saying "Bugzilla is currently tied to being run by Bugzilla".  Why does
> it
> >> matter what the backing implementation of Rietveld is?
> >>
> >> Primarily due to the two points that you trimmed from my email:
> >>
> >> Two other major issues jump out at me:
> >> - Authentication. This is related to the AppEngine tie-in.
> >> - Authorization.  Patch reviews need to reflect the access controls on
> the
> >> bugs that they are associated with.
> >>
> >> There are also concerns about access to the data store of the
> application,
> >> backup procedures, etc.  Our existing servers are well understood in
> this
> >> regard.   We've also found in the past that having services spread
> across
> >> different systems causes confusion when something goes wrong, for
> whatever
> >> reason, as it's not clear who to contact to address the problem.
> >
> > As I see it, these are the only non-trivial issues with using
> > rietveld. Things like not working with git are trivial fixes (e.g. git
> adds
> > "a/" and "b/" to the paths in the diff that need to be ignored). Also, I
> > really don't believe the intimidating UI is a problem in practice.
> Newcomers
> > get used to it very quickly.
> > I don't know enough about the rietveld code or appengine to say how
> > difficult it would be to address the authentication/authorization issues.
> > These would be the reason's to consider something like review-board
> instead.
> > My guess is that the access control bit is doable, but I think you'd
> > ultimately still need to sign in to AppEngine using a Google account.
> > For what it's worth, we've had next to zero maintenance effort go into
> > keeping rietveld running on appengine. As far as I know, it's been pretty
> > much stable and problem free. But I don't actually maintain it, so I
> can't
> > say that for sure. :)
> > Review-board would be considerably less effort than integrating something
> > directly into bugzilla. But rietveld would be less effort than
> review-board
> > if we can get the above issues addressed since there are a number of
> people
> > who already know the codebase willing to help out here.
> > It seems worth taking a look at how much work it would be to get
> > review-board setup and integrated with bugzilla.
> > Ojan
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090608/10dd69f4/attachment.html>