On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:
I would prefer a discussion on the mailing list. I think it's
everyone contributing to the project can state it's opinion and hear
Sounds good to me.
Here's some parts I can comment on briefly:
Commit and review rights
I agree that we should have a fair and open policy on commit and
review rights. Notwithstanding Alp's remarks that Apple has been
reasonable in administering this, I think open source projects thrive
on openness. I'm hoping we can improve the situation soon. One thing
we are working on now is putting together a complete list of current
committers anr reviewers to publish on the wiki.
Project planning should become more transparent. The mailing list
should be used for larger discussions or decisions that affect all
platforms, to give all involved parties a chance to comment.
I agree that large changes should be discussed on the mailing list.
I'll try to post information about Apple's near to mid term feature,
performance and architecture goals for the project to inform everyone
and for discussion.
* Platforms need to have an idea of when to expect the next stable
* Releases should be time based.
* Release schedules and a (loosely defined) roadmap should be
discussed and agreed upon inside the community.
These requests are pretty challenging to meet. We have a few
1) Currently more than half of development, and probably a bigger
proportion of core cross-platform work, is done by Apple engineers.
Also, most dogfood testing is currently done on the Mac platform via
nightlies. That means it is strongly advantageous to be relatively in
sync with Apple's release cycles; otherwise we'll be forced to do
stabilization and feature development based on Apple product cycle in
a vendor branch instead of on trunk. I think that would be a bad thing
for the project as a whole, since Apple's Safari releases would end up
out of sync with project releases.
2) Apple's general policy is to not comment on future product
releases, either dates or features. For the WebKit open source
project, it is obviously important to have shared discussion of the
overall roadmap. So we finesse this by discussing plans and roadmap in
general, and not details of the timetable.
3) As more organizations and companies ship WebKit-based products,
there will be more different vendor release cycles to consider.
I can tell you that Apple's drive for stable WebKit releases is likely
to become more frequent now that Safari 3 is out, and we are unlikely
to see a gap as big as the Safari 2 --> Safari 3 gap for the
We'll probably have to evolve our approach over time.
* The webkit.org/blog should aggregate the blogs of all contributors
(Surfin' Safari and blogs of external contributors)
I think I'd like to keep Surfin' Safari as a blog for WebKit
contributors where we also post occasionally Apple-focused info, and
where any significant contributor is welcome to post. But I think we
should add a planet.webkit.org type aggregator which includes Surfin'
Safari and other WebKit contributor blogs.
* The main webpage and the navigation bar should be platform agnostic
I think the main page mostly is. Many of the pages linked from the
sidebar have Mac or Safari specific info. However, that's not a matter
of policy but just happens to be what the pages started with. The
content is all in SVN and we welcome patches to add build info for
other platforms. If we get enough different platforms maybe we can use
a tab approach to split out instructions that are different per-
* Safari specific things should go in a subpage (with a prominent
link form the main page)
Is there anything on the main page that you consider Safari-specific?
* A free use WebKit logo would be great to have
I agree; I'm not a huge fan of the current one. We're thinking of
having a design contest, I expect Adam will be starting some
discussion about this.
webkit-dev mailing list