On Sat, Dec 12, 2009 at 6:19 PM, Holger Freyther <[email protected]> wrote: > On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote: >> I think questioning someone's priorities in an open source project is >> generally not polite, unless there is some direct relationship between >> different tasks. For example, if someone introduce a new feature >> (let's say support for parts of the FooML language) and it had lots of >> bugs, it might be reasonable to ask them to fix some of the bugs >> before implementing more FooML features. But that doesn't seem to be >> the case here. >> >> Ultimately, I think it's up to the Gtk port maintainers and the folks >> maintaining v8 bindings to decide whether they want to support and >> maintain this functionality, and to review the patch as they see fit. > > Hello Mike, All, > > I'm not questioning your priorities. I'm solely looking at this from a > maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big > software project) is that we are not done when landing a fundamental new > feature/configure option but it is really only the beginning. > > The questions are around, who is running a buildbot with this configuration > option, who will look at this buildbot, who will keep it building. In general > it is better to have less options (as these could be actually checked prior to > a release). So it is really not about me telling Mike what to do, but thinking > about what is maintainable for WebKit/GTK+. >
To be clear the dependency on Gtk itself is small. I'll push the code into a git repo somewhere and link to the bug on monday. Now of course I had to seriously munge the makefiles but they already suffer bit rot. You mention the new font system a refactoring of the makefiles is probably needed for a host of reasons the changes needed to compile V8 just expose this. My point is a refactoring of the makefiles to make the port easier to maintain is probably a must before the V8 support could come in and it would help the overall Gtk project. Of course given my track record I could also be the only one with that opinion and everyone else is happy. If so then forget the offer :) However I think we have overlapping areas of concern and if so bringing some sanity back to the build will help everyone both in making the official build feature set clear and allowing easy work on optional or experimental features. The Linux kernel had similar issues and resolved them. I know that the v8 patch pushed things over the edge to a ridiculous set of ifdefs. Perhaps autoconf allows nested features or perhaps feature bundles are the answer or meta config switches they set and unset a compatible group of options. I don't know the right answer just that its probably time to overhaul the build system a bit and I can help. > E.g. we have an experimental GLib Unicode implementation, and saving the > storage size for ICU (12 mb when not statically linked) is a pretty good > reason for some. > > At the end of the day I feel responsible for the Gtk+ port and I would just > like to know why it makes sense for "us" to maintain it. > > regards > holger. > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
