http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versio... Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that. It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time. Thanks
On Nov 23, 2007 12:31 PM, Alp Toker <alp@atoker.com> wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versio...
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
For what it is worth I think most of what was laid out in the above document is good. The project and web-site has a definite Apple/Safari focus, and this will become a problem as the other platforms mature. As one of the "lesser" platforms (Haiku) I think it would be good to have the project more platform independent in its process and web-site as much as the code.
It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time.
I don't know if I have been affected by this too much, but I do agree with this advice. Regards, Ryan
On 24/11/2007, at 09:04, Ryan Leavengood wrote:
On Nov 23, 2007 12:31 PM, Alp Toker <alp@atoker.com> wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versio...
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
For what it is worth I think most of what was laid out in the above document is good. The project and web-site has a definite Apple/Safari focus, and this will become a problem as the other platforms mature. As one of the "lesser" platforms (Haiku) I think it would be good to have the project more platform independent in its process and web-site as much as the code.
The website is in Subversion. If anyone feels changes should be made they are more than welcome to submit patches to the website via Bugzilla. Kind regards, Mark Rowe
On Nov 23, 2007, at 9:31 AM, Alp Toker wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versio...
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
I don't think this page is meant to represent an opinion of the whole project, but rather a set of requests from the QtWebKit developers from the project as a whole. I think it would be a good idea to discuss the substance of the requests on the mailing list. I have already discussed some offline with Lars and George. Are you guys up for discussing these topics by email? I am also happy to discuss further off-list.
It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time.
Actually, I'm somewhat concerned as well about the QtWebKit work drifting away from the core somewhat. Doing work primarily in a separate repository and then pushing changes upstream creates a situation where the Qt developers communicate less with the rest of the project, and makes other developers less aware of their changes. It also means more distance from project infrastructure like the buildbots. Qt guys, is there anything we could do to make it easier for you to work directly in the webkit.org repository? Regards, Maciej
On 23-Nov-07, at 5:59 PM, Maciej Stachowiak wrote:
On Nov 23, 2007, at 9:31 AM, Alp Toker wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision? action=diff&version=1
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
I don't think this page is meant to represent an opinion of the whole project, but rather a set of requests from the QtWebKit developers from the project as a whole. I think it would be a good idea to discuss the substance of the requests on the mailing list. I have already discussed some offline with Lars and George. Are you guys up for discussing these topics by email? I am also happy to discuss further off-list.
Exactly. It's our (QtWebKit) vision of what we think should happen. If that's not clear then we can adjust to make it more clear. I'm happy to discuss items via email too.
It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time.
Actually, I'm somewhat concerned as well about the QtWebKit work drifting away from the core somewhat. Doing work primarily in a separate repository and then pushing changes upstream creates a situation where the Qt developers communicate less with the rest of the project, and makes other developers less aware of their changes. It also means more distance from project infrastructure like the buildbots.
Qt guys, is there anything we could do to make it easier for you to work directly in the webkit.org repository?
We're kind of doing that - just with git. We aren't able to work inside the Safari 3 branch but git allows us to easily track it, merge into trunk, and work with more flexibility. We're not trying to drift away by any means. We're just putting a layer in between us and Safari 3 branch to make it easier to do what we need. We're still using the WebKit bugzilla and mailing lists for discussion and bug tracking. We also plan to continue using the build bots, though we will probably have to setup a special one to track the Safari 3 QtWebKit git branch. Unfortunately I don't think Subversion lends itself well to this model of development so there probably isn't much you can do short of switching to git. Really, right now I think the best thing is to just keep things status quo and let us deal with the administrative issues. One other added bonus of git is that people who don't have commit rights can still create their own branches in git and we can then very easily cherry pick the good changes (with changelog) into the main branch and then push upstream. It gives us instant review, allows new developers to work with the tools directly instead of emailing patches, and should not interfere with the normal procedures for granting commit and review rights. We spent quite some time coming up with a system that should, if anything, open up the process even more and make it easier for people to join. Our goal is specifically to prevent us from drifting away from the core while making our work patterns functional. If it turns out that we somehow drift away then we will immediately look at an alternative solution. For now, what we're dong just makes sense. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/
On Friday 23 November 2007 23:59:25 Maciej Stachowiak wrote:
On Nov 23, 2007, at 9:31 AM, Alp Toker wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&ver sion=1
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
The page clearly states that these are ideas of the people working on the Qt port of WebKit. George, Adam, Simon and myself had a face to face meeting last week, and this came up there, so we thought it's best to put things together before it get's lost in the day to day work again. This is by no means something we want to impose on the project, it's the things we feel could be changed and improved over time.
I don't think this page is meant to represent an opinion of the whole project, but rather a set of requests from the QtWebKit developers from the project as a whole. I think it would be a good idea to discuss the substance of the requests on the mailing list. I have already discussed some offline with Lars and George. Are you guys up for discussing these topics by email? I am also happy to discuss further off-list.
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 arguments.
It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time.
I don't think we have committed many changes that affected cross platform code. At least 95% of what we've done was purely inside the Qt specific parts. If we broke someone else's build I apologize, but usually we are tracking the buildbots after our changes to make sure we fix up any breakages that should happen.
Actually, I'm somewhat concerned as well about the QtWebKit work drifting away from the core somewhat. Doing work primarily in a separate repository and then pushing changes upstream creates a situation where the Qt developers communicate less with the rest of the project, and makes other developers less aware of their changes.
Just as a sidenote: Part of the communication problem is that efficient communication currently requires being on IRC all the time. I just got my second child a few weeks ago, and honestly do currently not have the possibility to do that.
It also means more distance from project infrastructure like the buildbots.
Qt guys, is there anything we could do to make it easier for you to work directly in the webkit.org repository?
The reasons are purely technical. The main reason we work as we do for the moment is that we need to stabilize our tree. We want to ship WebKit as part of Qt 4.4 in Q1/2008 and are now going into a feature freeze and stabilization phase for the Qt port. To be able to get a stable product out, we decided to base the stuff that will go into Qt 4.4 on the Safari-3 branch. Now Apple stated clearly (and I completely agree to that), that the Safari-3 branch is something they want to control, which means that we have to do our work in a branch of our own that tracks Safari-3. Doing that in SVN is a real pain and would be a huge waste of time we don't currently have. There is quite some work remaining to turn the Qt port into a completely polished release, so we unfortunately have to focus our resources on that branch. We are however trying our best to continue tracking trunk as well, but our resources are a bit strained just now, as we are currently trying to tie Qt 4.4 together. It should however get better in a few weeks from now when we enter our bug fixing phase for 4.4. As to what would make it easier to work in the webkit.org repository: Currently our main problem is the version control system used, that makes it very hard to work on a branch that follows another branch. I am not really happy that we are currently doing most work outside of the main repository, but we didn't see another possibility to make things work for us. That being said, our repository is basically a git mirror of SVN and does automatically pull in all changes happening in trunk. It's not that much different from other people using git on top of SVN apart from it being a more collaborative effort. Cheers, Lars
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 arguments.
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. Regards, Maciej
On Thursday 29 November 2007, Maciej Stachowiak wrote:
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 arguments.
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.
Thanks. I think your mail there is a good start :)
* 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.
I do agree that it makes sense to sync webkit releases with Safari releases. Not having a date for these is however a large challenge for others. If we don't have an idea, we can't really plan which WebKit version to base ourselves upon for Qt 4.5. This in turn implies that we can't tell our customers or the open source community which new features WebKit in Qt 4.5 will contain.
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.
Yes :)
* 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.
Sounds good to me. The main thing is that it would be great to have a central place where all WebKit related blogs/news appears. Currently you have to search on lots of different places for blogs about WebKit (labs.trolltech.com and planetkde.org for the Qt port, planet.gnome.org for the Gtk port and other places for other people). This is IMO unfortunate as it doesn't give the public a good enough view on how large the community really is.
* 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.
Sounds good. We'll see that we add more info for the Qt port in there over the next weeks.
* 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?
Mainly the nightlies stuff. I was more thinking that it will be important to have a link to a good page giving information about the Safari version prominently, as this is the port with the highest number of users.
* 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.
Great to hear :) Cheers, Lars
Lars Knoll wrote:
On Thursday 29 November 2007, Maciej Stachowiak wrote:
On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:
* 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.
Sounds good to me. The main thing is that it would be great to have a central place where all WebKit related blogs/news appears. Currently you have to search on lots of different places for blogs about WebKit (labs.trolltech.com and planetkde.org for the Qt port, planet.gnome.org for the Gtk port and other places for other people). This is IMO unfortunate as it doesn't give the public a good enough view on how large the community really is.
I can start working on setting up planet.webkit.org. I think it'll be a really nice resource.
* 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.
Great to hear :)
Yes, I will be sending mail about this soon to this list. -Adam
On Friday 23 November 2007 18:31:41 Alp Toker wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versi on=1
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
Apart from that name of the page what do you think about the content itself?
It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time.
Are you referring to the change to the .pro file that broke "make clean"? Simon
Simon Hausmann wrote:
On Friday 23 November 2007 18:31:41 Alp Toker wrote:
http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versi on=1
Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that.
Apart from that name of the page what do you think about the content itself?
I thought nobody was going to ask :-) It sounds mostly like hot air to me. "algorithm to obtain commit and review rights"? I'm sure Apple will agree with any request to give developers having a good track record and cohesion with the rest of the team commit and review status. There is an element of discretion here and I don't think you can just derive a formula for these decisions. I kind of like the charisma of Surfin' Safari (which evolved from Dave Hyatt's blog, right?) and think it would be a shame to see it turn into another blog aggregator. http://planet.webkit.org/ would be neat though. I can get on the case and set this up if we all agree here. Versioning is a technical matter rather than a "vision" issue. I'm sure we can develop a system for sharing versioning information with a little help from Mark. Release schedules, on the other hand, are a complex and contentious topic. A friend once remarked that working on WebKit TOT is "like sitting on a volcano" which occasionally hurls out new features and releases. Again, I think that this needn't be a "vision" issue but rather a whole new thread of discussion. At the end of the day, the Qt port is going to want to align with Qt releases, GTK+ is going to want to align with the GNOME platform and Apple is going to match OS X, so I wouldn't get my hopes up.
participants (8)
-
Adam Roben
-
Alp Toker
-
George Staikos
-
Lars Knoll
-
Maciej Stachowiak
-
Mark Rowe
-
Ryan Leavengood
-
Simon Hausmann