I think this is a constructive email, George. Thanks for writing
it. Specific responses below.
On Feb 16, 2007, at 10:29 PM, George Staikos wrote:
We made some great progress but it's an absolutely ridiculous
development model as far as getting real work done. So far we had:
1) Work outside webkit SVN to start the port
-> webkit renames and refactors hit us hard
There's not much to say here except that the porting layer was
obviously still under construction. Trying to build a house on top
of a foundation that is shifting is going to be hard. If the porting
efforts had begun now instead of months ago when the porting layer
was still in a high state of flux, there would not have been very
much pain.
2) Port again, also outside of WebKit SVN (note: we were doing a
very large number of commits/week. far more than now)
3) Spend far too much time merging from WebKit SVN, especially when
things like renames and refactors happen
These are problems that are solved by working in the WebKit SVN if
the later problems you mention are addressed.
4) Eventually give up and merge back to webkit SVN
5) End up in a ridiculous situation of having one member of the
porting team as the only person with rights to review the work.
Interesting, since that person has no-one who can review his work
under the formal rules. The guy who started the port, and the guy
who invented KHTML altogether are not given review rights.
6) Work slows down drastically as developers are discouraged and
are stuck in procedure that has relatively little value for the
given situation.
I agree that for work within a specific porting layer that it's clear
that the rules should be different, especially in the earlier stages
of development. I think there are several ways to address this issue:
(1) Branches - This is the way Nokia has been working. I don't
recommend it for any newly-starting ports, but it worked for Nokia
because they had done an initial implementation already. However the
rules are different for the Nokia branch. People have commit/review
access for that section and can basically use it as they see fit.
(If Nokia wants to make review optional, it's their branch, so that's
fine).
(2) I think we should allow for ports to operate in a similar fashion
on tip of tree if they need to. Basically within platform-specific
code (like say the Qt port), we should be much more open about
granting commit access to interested contributors and let the people
working on that port decide if they want to make review required or
not. This would allow people to - for example - fix build bustage
without having to consult anyone or seek review (assuming the fixes
don't impact core engine code or other platforms in any way).
For core engine code, being very locked down and paranoid is a good
thing, but I see no reason to apply that paranoia to porting layers.
dave
([EMAIL PROTECTED])
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
