Re: [webkit-dev] SVGNames.h and HTMLNames.h can not be found when build in windows...

[Adam Roben]

On Jan 10, 2008, at 9:23 PM, Wang Manson-a21065 wrote:


Build error as below
c:\cygwin\home\a21065\webkit\webcore\svg\SVGElement.h(33) : fatal  
error C1083: C

annot open include file: 'SVGNames.h': No such file or directory
...



Can some one help me?


SVGNames.h is generated in an earlier part of the build process (by  
the WebCoreGenerated project). There were probably errors before this  
one that prevented its generation. We'd have to see those earlier  
errors to know what went wrong. Did you follow the instructions on ?


-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[Oliver Hunt]

On 11/01/2008, at 10:54 AM, Mike Emmel wrote:

I think this approach will allow us to keep the main repository and
tree clean and foster the churn that makes open source development fun
and exciting.

Contributing to webkit is not a fun and exciting process at the  
moment.


There's already a git mirror of webkit trunk, and there's nothing  
stopping you from having a public facing version of your own git  
repository, but having a lax commit policy will just make life  
complicated in the long term -- say you work for many months off  
trunk, sure git will allow you to track trunk effectively, but when  
it comes to final commit time it will make reviewing the patch much  
harder as the entire patch will have to be reviewed at once...


As far as I was aware most large OSS projects had similar review  
requirements, so i'm not entirely sure how the WebKit project differs


--Oliver




On Jan 11, 2008 10:38 AM, Alp Toker <[EMAIL PROTECTED]> wrote:

Hey guys,

There's a lot of mobile WebKit expertise in different  
organisations and
from various individuals, but we haven't really done much to put  
it all

in one place so far.

Would you be interested in sharing your findings, internal  
documentation

and patches?

Some things I'd like to see:

  * Build fixes for various lightweight toolchains integrated into  
TOT


  * Documentation of optional defines used in the WebCore loader and
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE

  * Build instructions made public (Scratchbox, cross-compilation  
etc.)


  * Compiler flags

  * Bug workarounds for different architectures and toolchains

I'd love to see what Naiem's team is finding and fixing in the GTK+
port, what tweaks the iPhone and Android engineers are using, and the
lightweight libc fixes from Peter, and Collabora's findings on the  
Nokia

internet tablets all in one place.

When patches get merged, the WebKit team will help you maintain  
them so

contributing code can help reduce the burden of maintaining ports and
build fixes out-of-tree.

I have some material I've built up privately in the last year on ARM
including benchmarks and patches that I'd like to start sharing too.

I do think we can get more done if we work together here. I've set  
up a

wiki page -- please edit this with your findings and suggestions:

   http://trac.webkit.org/projects/webkit/wiki/Mobile

You can register an account on the wiki here:

   http://trac.macosforge.org/projects/webkit/register
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)

[Mark Rowe]

[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, .  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, .  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)

[Mike Emmel]

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, 
>   >.  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, 
>   >.  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: [webkit-dev] Pulling together on WebKit Mobile

[Oliver Hunt]

I have no problems with the commit requirements for the main tree.
This is more about a collaboration area.
It make more sense for WebKit.org to host a collaboration area.

And its a good way to allow developers to build up a work history to
ask for main commit rights.

Its a public work area and why would it effect eventual mainline
submissions if the code is crufty its rejected.


Why can't http://bugs.webkit.org be used for this?  It's what we've  
been using for

what, 3 years now? 4?

bugs.w.o has a single major advantage over git: it allows actual  
communication -- making code available != communication -- b.w.o  
allows you to place updated patches, respond to feedback, and get  
feedback in one location that provides both an archive and locality.   
Afaict the git "equivalent" is to discuss your patch out of band in a  
mailing list, most likely including the original patch in the mail --  
so patch discussion still happens outside of git, and later when  
someone comes back to see why decisions were made in a specific patch  
they have to search for scattered posts in a mailing list to try and  
find those emails discussing that patch.


I'm also unsure how you expect this to help contributors gain  
credibility -- the mechanisms by which this happens, and how commit  
rights, etc are developed are well disclosed on webkit.org.  I don't  
see how git would help this -- an ability to write code is only part  
of the requirements, a developer needs to demonstrate good  
communication skills, and an ability to respond to feedback, etc.   
Working outside of b.w.o removes a number of avenues of real  
discussion and record so to me would seem more likely to hinder the  
credibility of a developer rather than help it.




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.

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.

As of now the patch sits in my git tree unsubmitted.


I fail to see why this patch could not just be placed in b.w.o as  
with any other feature or bugfix patch


--Oliver

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVGNames.h and HTMLNames.h can not be found when build in windows...

[Brent Fulgham]

Make sure you have all of the Cygwin utilities available in your path when
you build.  If you do not have gperf, many of the auto-generated files will
not be created and you will get errors such as you describe.

Good luck!

-Brent

On Jan 10, 2008 6:23 PM, Wang Manson-a21065 <[EMAIL PROTECTED]> wrote:

>  Build error as below
> c:\cygwin\home\a21065\webkit\webcore\svg\SVGElement.h(33) : fatal error
> C1083: C
> annot open include file: 'SVGNames.h': No such file or directory
> ...
>
>
>
> Can some one help me?
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[Mike Emmel]

On Jan 11, 2008 11:29 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
>
> On 11/01/2008, at 10:54 AM, Mike Emmel wrote:
> > I think this approach will allow us to keep the main repository and
> > tree clean and foster the churn that makes open source development fun
> > and exciting.
> >
> > Contributing to webkit is not a fun and exciting process at the
> > moment.
>
> There's already a git mirror of webkit trunk, and there's nothing
> stopping you from having a public facing version of your own git
> repository, but having a lax commit policy will just make life
> complicated in the long term -- say you work for many months off
> trunk, sure git will allow you to track trunk effectively, but when
> it comes to final commit time it will make reviewing the patch much
> harder as the entire patch will have to be reviewed at once...
>
> As far as I was aware most large OSS projects had similar review
> requirements, so i'm not entirely sure how the WebKit project differs
>
> --Oliver
>

I have no problems with the commit requirements for the main tree.
This is more about a collaboration area.
It make more sense for WebKit.org to host a collaboration area.

And its a good way to allow developers to build up a work history to
ask for main commit rights.

Its a public work area and why would it effect eventual mainline
submissions if the code is crufty its rejected.

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.

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.

As of now the patch sits in my git tree unsubmitted.


>
> >
> >
> > On Jan 11, 2008 10:38 AM, Alp Toker <[EMAIL PROTECTED]> wrote:
> >> Hey guys,
> >>
> >> There's a lot of mobile WebKit expertise in different
> >> organisations and
> >> from various individuals, but we haven't really done much to put
> >> it all
> >> in one place so far.
> >>
> >> Would you be interested in sharing your findings, internal
> >> documentation
> >> and patches?
> >>
> >> Some things I'd like to see:
> >>
> >>   * Build fixes for various lightweight toolchains integrated into
> >> TOT
> >>
> >>   * Documentation of optional defines used in the WebCore loader and
> >> elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE
> >>
> >>   * Build instructions made public (Scratchbox, cross-compilation
> >> etc.)
> >>
> >>   * Compiler flags
> >>
> >>   * Bug workarounds for different architectures and toolchains
> >>
> >> I'd love to see what Naiem's team is finding and fixing in the GTK+
> >> port, what tweaks the iPhone and Android engineers are using, and the
> >> lightweight libc fixes from Peter, and Collabora's findings on the
> >> Nokia
> >> internet tablets all in one place.
> >>
> >> When patches get merged, the WebKit team will help you maintain
> >> them so
> >> contributing code can help reduce the burden of maintaining ports and
> >> build fixes out-of-tree.
> >>
> >> I have some material I've built up privately in the last year on ARM
> >> including benchmarks and patches that I'd like to start sharing too.
> >>
> >> I do think we can get more done if we work together here. I've set
> >> up a
> >> wiki page -- please edit this with your findings and suggestions:
> >>
> >>http://trac.webkit.org/projects/webkit/wiki/Mobile
> >>
> >> You can register an account on the wiki here:
> >>
> >>http://trac.macosforge.org/projects/webkit/register
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo/webkit-dev
> >>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
diff --git a/WebKit/gtk/Api/webkitgtkpage.cpp b/WebKit/gtk/Api/webkitgtkpage.cpp
index dabc685..ba271da 100644
--- a/WebKit/gtk/Api/webkitgtkpage.cpp
+++ b/WebKit/gtk/Api/webkitgtkpage.cpp
@@ -47,7 +47,10 @@
 #include "PlatformKeyboardEvent.h"
 #include "PlatformWheelEvent.h"
 #include "SubstituteData.h"
-
+#ifndef NDEBUG
+#include "RenderTreeAsText.h"
+#include 
+#endif
 
 using namespace WebKit;
 using namespace WebCore;
@@ -75,22 +78,46 @@ static gboolean webkit_page_expose_event(GtkWidget* widget, GdkEventExpose* even
 {
 Frame* frame = core(getFrameFromPage(WEBKIT_PAGE(widget)));
 GdkRectangle clip;
+cairo_t* cr;
 gdk_region_get_clipbox(event->region, &clip);
-cairo_t* cr = gdk_cairo_create(event->window);
+
+//quartz backend is b

[webkit-dev] Pulling together on WebKit Mobile

[Alp Toker]

Hey guys,

There's a lot of mobile WebKit expertise in different organisations and 
from various individuals, but we haven't really done much to put it all 
in one place so far.


Would you be interested in sharing your findings, internal documentation 
and patches?


Some things I'd like to see:

 * Build fixes for various lightweight toolchains integrated into TOT

 * Documentation of optional defines used in the WebCore loader and 
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE


 * Build instructions made public (Scratchbox, cross-compilation etc.)

 * Compiler flags

 * Bug workarounds for different architectures and toolchains

I'd love to see what Naiem's team is finding and fixing in the GTK+ 
port, what tweaks the iPhone and Android engineers are using, and the 
lightweight libc fixes from Peter, and Collabora's findings on the Nokia 
internet tablets all in one place.


When patches get merged, the WebKit team will help you maintain them so 
contributing code can help reduce the burden of maintaining ports and 
build fixes out-of-tree.


I have some material I've built up privately in the last year on ARM 
including benchmarks and patches that I'd like to start sharing too.


I do think we can get more done if we work together here. I've set up a 
wiki page -- please edit this with your findings and suggestions:


  http://trac.webkit.org/projects/webkit/wiki/Mobile

You can register an account on the wiki here:

  http://trac.macosforge.org/projects/webkit/register
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[Mike Emmel]

I think one of the biggest stumbling blocks is the lack of a shared
workspace for development.

The patch approach is good for bugs but falls apart when multiple
people from different organizations are working on new code.

However I like the review process in place before code is included in
the main tree.

Git with its builtin ability to chain repositories easily makes a
sensible choice for solving this problem.

So I would like to propose that we have a public git repository set up
that has fairly lax commit rules.
This repo can track the main repository and we should bugs to
reference git branches in the development repository.

This will allow us to publicly stage development for inclusion into
the main repo and make it easy to upgrade bug reports as the head
changes.

And most importantly it would move a lot of intermediate development
out of private repositories and into
a sharable public arena.

Next it gives people a work history that can be reviewed when
considering allowing main repo privileges.


I think this approach will allow us to keep the main repository and
tree clean and foster the churn that makes open source development fun
and exciting.

Contributing to webkit is not a fun and exciting process at the moment.



On Jan 11, 2008 10:38 AM, Alp Toker <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> There's a lot of mobile WebKit expertise in different organisations and
> from various individuals, but we haven't really done much to put it all
> in one place so far.
>
> Would you be interested in sharing your findings, internal documentation
> and patches?
>
> Some things I'd like to see:
>
>   * Build fixes for various lightweight toolchains integrated into TOT
>
>   * Documentation of optional defines used in the WebCore loader and
> elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE
>
>   * Build instructions made public (Scratchbox, cross-compilation etc.)
>
>   * Compiler flags
>
>   * Bug workarounds for different architectures and toolchains
>
> I'd love to see what Naiem's team is finding and fixing in the GTK+
> port, what tweaks the iPhone and Android engineers are using, and the
> lightweight libc fixes from Peter, and Collabora's findings on the Nokia
> internet tablets all in one place.
>
> When patches get merged, the WebKit team will help you maintain them so
> contributing code can help reduce the burden of maintaining ports and
> build fixes out-of-tree.
>
> I have some material I've built up privately in the last year on ARM
> including benchmarks and patches that I'd like to start sharing too.
>
> I do think we can get more done if we work together here. I've set up a
> wiki page -- please edit this with your findings and suggestions:
>
>http://trac.webkit.org/projects/webkit/wiki/Mobile
>
> You can register an account on the wiki here:
>
>http://trac.macosforge.org/projects/webkit/register
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
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)

[Mark Rowe]

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  ,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)

[Mike Emmel]

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  ,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
be

Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)

[Mark Rowe]

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  ,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
___