On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:

I would prefer a discussion on the mailing list. I think it's important that everyone contributing to the project can state it's opinion and hear all

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 WebKit version.
* 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 conflicting constraints:

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 foreseeable future.

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- platform.

* 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

Reply via email to