Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Hi, Le 12 janv. 08 à 08:51, Mark Rowe a écrit : Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Sorry to interfere in your discussion :) Mike- I'm not sure we need git at Pleyo, and I am reluctant to the idea that having git would miraculously solve the problem of proposing our changes to the community. I have, weeks ago, asked again and again for some kind of access to the official repository, whether a branch or whatever so that we can start showing of that our changes do not break everything and are not that far away, so that the community can assess what is worth being merged and what is not. On the other hand, Mark, I don't think it's fair to say that in the current state of both webkit trunk and our version, we could simply deposit patchs on bugzilla and that it would be the solution, we have too many changes which are often related to each others, so I assume that it would not work, which is why I made the request mentioned above. I have no answer yet wrt to this proposal so I assume it has not yet been rejected ;) Best regards, Jean-Charles -- Jean-Charles Verdié Join OWB team on freenode IRC, channel #owb Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Then make it SVN I don't care. If git is that big of a hurdle then create a collaboration are using SVN. I did not mean to get into a git vs svn match. Git just seemed to me to be a better choice for the type of branching and merging and needed for a collaboration area. SVN, cvs rcs, sccs anything is better than nothing. Right now we have nothing. On Jan 11, 2008 11:51 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 18:13, Mike Emmel wrote: Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've worked with a number of people that have been interested in experimenting with Git for use with WebKit. The feedback I have received from the majority of them is that git is much less friendly to use than Subversion, and that the documentation is hard to follow for new users. It does have its benefits once you understand how to use it, but it has a hell of a learning curve before you get to that point. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. If you're going to write off all possible solutions except the one you have set your mind on then I feel this discussion is not going to get very far. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. We clearly have different definitions of support. git.webkit.org provides a git-svn mirror. However, working with that mirror is left up to the end user. We provide no documentation for it or expectations that all our tools will function correctly. You also appear to be under the impression that because a given tool is used by another project it must be suitable for adoption by WebKit. The projects you mention have different development models, processes and supported platforms that may make the tool more suitable for them. Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Your webkit ports list has none of this work listed. http://trac.webkit.org/projects/webkit/wiki It's a wiki. I would encourage you to add info about these projects. Your QT port does not have the git working repository linked in a obvious manner if at all. http://trac.webkit.org/projects/webkit/wiki/QtWebKit Sure it does: click Information for Contributors. I see no reason to have this stuff scattered across the internet. Why can't webkit.org offer to host these ports ? I have already outlined the reasons why *I* feel it is premature for the WebKit project to do this at this time. If you feel strongly about this, I would suggest you trade talk for action
Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
[This is drifting far from Alp's original email. I hope the points he raised are not overlooked due to discussion on this very tangential topic.] On 12/01/2008, at 06:55, Mike Emmel wrote: And its a good way to allow developers to build up a work history to ask for main commit rights. We already have a well-defined policy for how this is handled, http://webkit.org/coding/commit-review-policy.html . I don't see what hosting git repositories has to do with Subversion commit access. I have a patch for example to allow the gtk webkit to run on OSX. But its a workaround for a bug in the cairo OSX port. I'd like to be able to get the patch public and work with the cairo OSX port maintainer to explain why I did what I did and what he could do to cairo to fix OSX cairo. Without a public work area this sort of problem is difficult to work on. Assuming cairo is fixed then we would need to figure out version info for the OSX port of GTK etc etc. I've found email works really well for discussing patches in the past. Indeed, that's what we use for a lot of patch discussion inside Apple. Would an official, public git repository make this easier? Possibly. A git repository for collaboration is a nicety, but hardly a necessity. As Oliver mentioned, it is not at all difficult to publish your own public git repository. Being able to run the OSX port and the gtk port at the same time on OSX is a nice feature. Other open source ports such as QT might want a similar workspace for similar problems. Staikos Computing Services provides something similar to what you describe for those collaborating on the Qt port, http://trac.webkit.org/projects/webkit/wiki/QtWebKitContrib . While I would prefer it were hosted somewhere more official (eg, git.webkit.org alongside the git mirror of SVN), I have heard very few requests for this from outside the Qt developer community. It is something I am interested in doing in the future, but it takes planning and time that I can better spend elsewhere at present. As of now the patch sits in my git tree unsubmitted. Do you consider using git to be a requirement for you to contribute at all to WebKit? - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 12:14 PM, Mark Rowe [EMAIL PROTECTED] wrote: [This is drifting far from Alp's original email. I hope the points he raised are not overlooked due to discussion on this very tangential topic.] On 12/01/2008, at 06:55, Mike Emmel wrote: And its a good way to allow developers to build up a work history to ask for main commit rights. We already have a well-defined policy for how this is handled, http://webkit.org/coding/commit-review-policy.html . I don't see what hosting git repositories has to do with Subversion commit access. I have a patch for example to allow the gtk webkit to run on OSX. But its a workaround for a bug in the cairo OSX port. I'd like to be able to get the patch public and work with the cairo OSX port maintainer to explain why I did what I did and what he could do to cairo to fix OSX cairo. Without a public work area this sort of problem is difficult to work on. Assuming cairo is fixed then we would need to figure out version info for the OSX port of GTK etc etc. I've found email works really well for discussing patches in the past. Indeed, that's what we use for a lot of patch discussion inside Apple. Would an official, public git repository make this easier? Possibly. A git repository for collaboration is a nicety, but hardly a necessity. As Oliver mentioned, it is not at all difficult to publish your own public git repository. I never claimed it was a necessity I just think it would be a very nice to have. And I think it would foster getting more code ready for submission faster and easier. As far as the current process for submission goes nothing wrong with it. Being able to run the OSX port and the gtk port at the same time on OSX is a nice feature. Other open source ports such as QT might want a similar workspace for similar problems. Staikos Computing Services provides something similar to what you describe for those collaborating on the Qt port, http://trac.webkit.org/projects/webkit/wiki/QtWebKitContrib . While I would prefer it were hosted somewhere more official (eg, git.webkit.org alongside the git mirror of SVN), I have heard very few requests for this from outside the Qt developer community. It is something I am interested in doing in the future, but it takes planning and time that I can better spend elsewhere at present. As of now the patch sits in my git tree unsubmitted. Do you consider using git to be a requirement for you to contribute at all to WebKit? I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. As far as small side projects like WebKit on OSX-GTK yes I consider it a requirement since Its something that makes sense to share with a broader community. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. Back to the OSX-GTK example it should be branched from the working gtk/webkit repository that the gtk developers are using for work in progress but ? And even better to see the latest QT work from the same git repo. Did the QT guys implement something that could be used as a guide for the GTK port but not land it in the main tree ? For me having this sort of work area would be very useful. Hopefully others feel the same way. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On 12/01/2008, at 07:55, Mike Emmel wrote: I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. The process you describe is vague and untested in the context of WebKit. The process we have now works reasonably well (well enough) for a large number of developers. There are some situations, none of which are particularly common, in which it is less efficient than it could be: two or more developers working together to implement a single feature is the one that springs to mind. Addressing these situations is clearly desirable, but I don't believe it's as simple as saying that git will magically fix things. It brings with it a new set of problems that most WebKit developers are not familiar with, and is much slower than SVN when interacting with an SVN repository, and currently has poor Windows support. Adopting git in a semi-official manner like you mention would require improving tool support and documentation such that any WebKit developer could deal with the new workflow if needed. In itself, this is not a small task. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. For me having this sort of work area would be very useful. I don't disagree that it would be useful. Part of the point of Git is that it is distributed in nature. This allows individuals to use git if they desire, and to experiment and come up with a workflow that fits with the existing WebKit tools and processes. Once tools have improved and a common idea of the right workflow to use has evolved, we should consider looking into adopting Git more officially. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 1:26 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 07:55, Mike Emmel wrote: I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. The process you describe is vague and untested in the context of WebKit. The process we have now works reasonably well (well enough) for a large number of developers. There are some situations, none of which are particularly common, in which it is less efficient than it could be: two or more developers working together to implement a single feature is the one that springs to mind. Addressing these situations is clearly desirable, but I don't believe it's as simple as saying that git will magically fix things. It brings with it a new set of problems that most WebKit developers are not familiar with, and is much slower than SVN when interacting with an SVN repository, and currently has poor Windows support. Adopting git in a semi-official manner like you mention would require improving tool support and documentation such that any WebKit developer could deal with the new workflow if needed. In itself, this is not a small task. Why ? If they want to use it they can if they prefer svn then they should work to get commit rights. I prefer that a small number of developers have commit rights to the main svn like it is now. This is far less than the number of developers that can contribute to webkit and forcing them to work with patches is simply cumbersome. Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. Also having the GNUSstep port and it looks like a number of other WebKit related projects lost over on a generic server is not a good thing. A collaboration under webkit.org would bring these projects back under webkit.org where they belong. For me having this sort of work area would be very useful. I don't disagree that it would be useful. Part of the point of Git is that it is distributed in nature. This allows individuals to use git if they desire, and to experiment and come up with a workflow that fits with the existing WebKit tools and processes. Once tools have improved and a common idea of the right workflow to use has evolved, we should consider looking into adopting Git more officially. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. Back to immediate needs. For the Gtk-OSX work it has one very useful feature it would be the only port that could be trivially switched between freetype rendering and ATSUI for fonts. Having a version of webkit that could be flipped between two standard font engines is very useful when looking at font related layout
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On 12/01/2008, at 18:13, Mike Emmel wrote: Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've worked with a number of people that have been interested in experimenting with Git for use with WebKit. The feedback I have received from the majority of them is that git is much less friendly to use than Subversion, and that the documentation is hard to follow for new users. It does have its benefits once you understand how to use it, but it has a hell of a learning curve before you get to that point. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. If you're going to write off all possible solutions except the one you have set your mind on then I feel this discussion is not going to get very far. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. We clearly have different definitions of support. git.webkit.org provides a git-svn mirror. However, working with that mirror is left up to the end user. We provide no documentation for it or expectations that all our tools will function correctly. You also appear to be under the impression that because a given tool is used by another project it must be suitable for adoption by WebKit. The projects you mention have different development models, processes and supported platforms that may make the tool more suitable for them. Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Your webkit ports list has none of this work listed. http://trac.webkit.org/projects/webkit/wiki It's a wiki. I would encourage you to add info about these projects. Your QT port does not have the git working repository linked in a obvious manner if at all. http://trac.webkit.org/projects/webkit/wiki/QtWebKit Sure it does: click Information for Contributors. I see no reason to have this stuff scattered across the internet. Why can't webkit.org offer to host these ports ? I have already outlined the reasons why *I* feel it is premature for the WebKit project to do this at this time. If you feel strongly about this, I would suggest you trade talk for action and improve the git compatibility of our tools, document processes for working with git against WebKit, and investigate precisely how your ideal result would work (what infrastructure would be needed, what workflow should be used, what changes to tools this would require). Simply dismissing the issues that I raised does nothing to address them. - Mark smime.p7s Description: S/MIME cryptographic signature
