It's time to remove the Haiku port
On April 9, 2010, I wrote an email to webkit-dev asking if it was time to remove the Haiku port: http://old.nabble.com/Archiving-the-Haiku-port--(was-WebKit2-and-all-that-ja... At the time, the port appeared inactive. Stephan Assmus and Maxime Simon wrote that they planned to continue development of the port. As far as I can tell, neither of them have contributed a patch to WebKit since May 3, 2010. http://trac.webkit.org/search?q=superstippi&changeset=on http://trac.webkit.org/search?q=maxime&changeset=on In the past year, http://trac.webkit.org/log/trunk/Source/WebKit/haiku and http://trac.webkit.org/log/trunk/Source/WebCore/platform/haiku have been modified 70 times by non-Haiku contributors and zero times by Haiku contributors. As part of our effort to reduce complexity in WebKit, I believe it is now time to remove the Haiku port. Adam
On Sun, Sep 25, 2011 at 9:34 AM, Adam Barth <abarth@webkit.org> wrote:
As part of our effort to reduce complexity in WebKit, I believe it is now time to remove the Haiku port.
Perhaps it would make sense to have a small set of simple rules written down somewhere that would justify the WebKit developers in removing any given port from upstream. That way it would be a bit more impersonal and natural (like a tornado destroying your house) and less likely to be perceived as a personal attack. A number of months of inactivity sounds like the main thing to consider here, as you point out, so we could just make it official. Xan
On Sun, Sep 25, 2011 at 2:16 AM, Xan Lopez <xan@gnome.org> wrote:
On Sun, Sep 25, 2011 at 9:34 AM, Adam Barth <abarth@webkit.org> wrote:
As part of our effort to reduce complexity in WebKit, I believe it is now time to remove the Haiku port.
Perhaps it would make sense to have a small set of simple rules written down somewhere that would justify the WebKit developers in removing any given port from upstream. That way it would be a bit more impersonal and natural (like a tornado destroying your house) and less likely to be perceived as a personal attack.
A number of months of inactivity sounds like the main thing to consider here, as you point out, so we could just make it official.
Yeah, I'm not sure where we should draw the line, but this case seems pretty clearly in the "unmaintained" camp, as was the old Android port. Maybe a good rule of thumb is something like if the community is spending more effort maintaining a port over a long period of time than the nominal maintainers of that port, then it's a sign that the port is creating negative value for the project. (That's why I included the statistics about the community contributing 70 patches to WebKit/haiku and WebCore/platform/haiku over the past year and the nominal maintainers contributing zero.) In this case also, I feel like when we discussed this issue over a year and a half ago, Stephan and Maxime said they were going to actively maintain and improve the port, specifically over the summer of 2010. As far as I can tell, that never happened. In that sense, I feel like we've already given them the benefit of the doubt. I hope no one takes this personally. I certainly have no ill will towards either Stephan or Maxime. All my interactions with them in the past have been positive. It's just time for the project to move on. Adam
I think removing Haiku port is a good thing given they don't even have build bots or EWS bots. We can't even tell if they compile or not. On Sun, Sep 25, 2011 at 2:30 AM, Adam Barth <abarth@webkit.org> wrote:
Yeah, I'm not sure where we should draw the line, but this case seems pretty clearly in the "unmaintained" camp, as was the old Android port. Maybe a good rule of thumb is something like if the community is spending more effort maintaining a port over a long period of time than the nominal maintainers of that port, then it's a sign that the port is creating negative value for the project.
I'm not sure. For one-person/small ports, this might always be the case because they won't be able to contribute at the rate other ports do. In this case also, I feel like when we discussed this issue over a
year and a half ago, Stephan and Maxime said they were going to actively maintain and improve the port, specifically over the summer of 2010. As far as I can tell, that never happened. In that sense, I feel like we've already given them the benefit of the doubt.
Following this pattern, giving a warning then waiting for some period of time might be sufficient. e.g. 1. Warn the port (probably on webkit-dev) 2. Wait for six months If there's no activity in step 2 to counter the argument, then remove the port. - Ryosuke
Following this pattern, giving a warning then waiting for some period of time might be sufficient. e.g. Warn the port (probably on webkit-dev) Wait for six months If there's no activity in step 2 to counter the argument, then remove the port.
You might think this leniency is friendly to port authors. I don't. Leniency is friendly to the author of the port you're considering removing, but unfriendly to all other port authors, for two reasons: 1. It decreases the overall quality of the code everyone shares, inhibits new features, and slows development. 2. If we codify a high barrier to exit for ports, we're likely to need a corresponding high barrier to entry. We'll need to make it harder for new ports to enter the project, for fear that they'll go stale but we'll still have to limp along with them in the tree. I tend to think that the reverse is the best policy: Low barrier to entry, low barrier to exit. This keeps the project open and growing, but also ensures that it can move forward without getting bogged down in unmaintained or poorly maintained ports. Barrier to entry: Send email to webkit-dev, get a reviewer to r+ a patch. Barrier to exit: Rough consensus among reviewers that a port is stale and/or a maintenance burden. Geoff
Fair enough. Rough consensus among reviewers sound good to me. - Ryosuke On Sep 25, 2011 11:16 AM, "Geoffrey Garen" <ggaren@apple.com> wrote:
Following this pattern, giving a warning then waiting for some period of time might be sufficient. e.g. Warn the port (probably on webkit-dev) Wait for six months If there's no activity in step 2 to counter the argument, then remove the port.
You might think this leniency is friendly to port authors. I don't. Leniency is friendly to the author of the port you're considering removing, but unfriendly to all other port authors, for two reasons:
1. It decreases the overall quality of the code everyone shares, inhibits new features, and slows development.
2. If we codify a high barrier to exit for ports, we're likely to need a corresponding high barrier to entry. We'll need to make it harder for new ports to enter the project, for fear that they'll go stale but we'll still have to limp along with them in the tree.
I tend to think that the reverse is the best policy: Low barrier to entry, low barrier to exit. This keeps the project open and growing, but also ensures that it can move forward without getting bogged down in unmaintained or poorly maintained ports.
Barrier to entry: Send email to webkit-dev, get a reviewer to r+ a patch. Barrier to exit: Rough consensus among reviewers that a port is stale and/or a maintenance burden.
Geoff
On Sun, Sep 25, 2011 at 9:12 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:
On Sun, Sep 25, 2011 at 2:30 AM, Adam Barth <abarth@webkit.org> wrote:
Yeah, I'm not sure where we should draw the line, but this case seems pretty clearly in the "unmaintained" camp, as was the old Android port. Maybe a good rule of thumb is something like if the community is spending more effort maintaining a port over a long period of time than the nominal maintainers of that port, then it's a sign that the port is creating negative value for the project.
I'm not sure. For one-person/small ports, this might always be the case because they won't be able to contribute at the rate other ports do.
I think any time the larger community is spending more effort than the port authors on a particular port we should be wary about keeping the port. Certainly that indicates that either our base-costs for having a port are too high (our platform abstraction is poor, etc.) or that the port maintainers aren't active enough in the project. -eric
On Mon, Sep 26, 2011 at 1:34 AM, Eric Seidel <eric@webkit.org> wrote:
I think any time the larger community is spending more effort than the port authors on a particular port we should be wary about keeping the port.
Yes this is totally reasonable.
Certainly that indicates that either our base-costs for having a port are too high (our platform abstraction is poor, etc.) or that the port maintainers aren't active enough in the project.
I think it is a little of both. The WebKit platform abstraction could definitely use improvement, as I'm sure many of you know. Plus WebKit changes REALLY, REALLY fast. For a project like Haiku which is strictly open source and volunteer developer driven, it is hard to keep a port up-to-date. The fact that so many changes were needed in our files without us making improvement or changes in our actual port may say something. Personally I would have told you not to update our files and just let them be broken if we didn't update them. The fact that so much work is needed from developers besides the port developers to maintain a more slowly developing port indicates a problem with WebKit. Well maybe not a problem, but there may need to be a policy of letting smaller ports maintain their own files. On another note, the reply-to on this mailing list is just broken :/ -- Regards, Ryan
Hello all, Sorry for the delay in response to this, I don't follow this mailing list closely, obviously. I just happened to search for Haiku, and was not too shocked to see this message. Given that the Haiku port has now been removed (in fact, Adam did it right on September 25 when this message was sent), clearly I'm way too late. On Sun, Sep 25, 2011 at 3:34 AM, Adam Barth <abarth@webkit.org> wrote:
In the past year, http://trac.webkit.org/log/trunk/Source/WebKit/haiku and http://trac.webkit.org/log/trunk/Source/WebCore/platform/haiku have been modified 70 times by non-Haiku contributors and zero times by Haiku contributors.
I am so sorry that this has happened! I was the original porter for the Haiku WebKit port and have continued to work on it recently. Unfortunately the Haiku community is a small group of people and most of the developers spend their time working on Haiku itself. We really appreciate the efforts to keep the Haiku port updated as things have changed in WebKit. The primary problem with our port right now is some of the developers made the choice (which I objected to) to make our own Subversion repo containing the WebKit code to make it easier (in their eyes) to develop the port. Once Stephan no longer was working on it, this clone became very out of date. Making things worse was the great code re-organizing which occurred a while ago here at WebKit (the move to Source, etc.)
As part of our effort to reduce complexity in WebKit, I believe it is now time to remove the Haiku port.
So as I mentioned this has already been done. Haiku itself is far from dead. We aren't a huge project but we have many active developers and multiple commits a day. We also still plan to make use of WebKit. I guess we are at a crossroads. I would much prefer not to have to maintain our own custom repo of WebKit. But it seems we have become more of a burden than a help on WebKit, but I suppose that is the case for most ports outside of the popular platforms. Where can we go from here? What does the WebKit project need to see from the Haiku maintainers to have us be a supported port again? Again I'm sorry for the lack of activity over the years but as you can imagine it is hard to work on an entire platform port for WebKit in one's spare time. We had to hire Stephan as a contractor to get all the work we got from him, and probably from your perspective that was nothing. -- Regards, Ryan
On Thu, Nov 3, 2011 at 7:32 PM, Ryan Leavengood <leavengood@gmail.com>wrote:
The primary problem with our port right now is some of the developers made the choice (which I objected to) to make our own Subversion repo containing the WebKit code to make it easier (in their eyes) to develop the port.
Where can we go from here? What does the WebKit project need to see from the Haiku maintainers to have us be a supported port again?
It seems like either you should be a private fork/port, or a public upstreamed one, but not both. If you want to live in the upstream tree, I think most of your development work should land quickly in public. If you want to work in a separate repository without landing changes back upstream quickly*, I think it's better to stay private until the point at which that changes. *At most I don't think your private repo should be more than a couple weeks off the public repo. Based on our experience with the Chromium port I think it would be far easier on your group to be public and do development directly in the public tree. PK
On Fri, Nov 4, 2011 at 12:33 PM, Peter Kasting <pkasting@google.com> wrote:
It seems like either you should be a private fork/port, or a public upstreamed one, but not both. If you want to live in the upstream tree, I think most of your development work should land quickly in public. If you want to work in a separate repository without landing changes back upstream quickly*, I think it's better to stay private until the point at which that changes.
Yes, this was definitely the hard lesson we learned, and as I'll describe below we are going to move to the latter set up for now.
*At most I don't think your private repo should be more than a couple weeks off the public repo.
Most definitely, I will strive to do that from now on :)
Based on our experience with the Chromium port I think it would be far easier on your group to be public and do development directly in the public tree.
That is definitely our end goal. But it seems at this point the Haiku port is too much of a burden to the WebKit community. I talked to Adam Barth in IRC last night and we came to an agreement that it is best *for now* if Haiku maintains a Git repo cloned off the WebKit repo with a branch containing our port. When our port is further along with layout tests working, most of the platform files implemented, a Buildbot, and maintainers with the time and skill to keep our port up-to-date, we can explore putting our code back in the public WebKit repo. This puts the burden on maintaining our port where it belongs: with our developers. It won't always be fun doing it this way, but I think using Git will help (as compared to Subversion which is where our current copy of WebKit is, and now almost 42,000 changesets behind.) Actually regarding the 42,000 changesets: these have all come in the last year and a half (!!!!), and are almost as many changesets as ever came before in the current WebKit repo. This is exponential growth! How is a small port possibly suppose to stay up-to-date under those conditions? Of course this just means that WebKit is a vibrant project and you cannot be faulted for that, but I think with this onslaught of changes it may be time to reconsider past methods of keeping ports up-to-date. Adam tells me Google has two full-time engineers keeping the Chromium port up-to-date. I think there is room for improvement in this area. Actually I have various thoughts about WebKit platform code which I'm sure many of you would agree with, but I can express those in another email. The short version is WebCore should have no platform code or PLATFORM macros and all platform code should plug in using clean abstract classes and delegates. Maybe this is an area where I or other Haiku developers can give back to the WebKit community. I just hope that when that time comes (and maybe sooner rather than later) the WebKit community will let us back in and quickly apply our patches. -- Regards, Ryan
On Fri, Nov 4, 2011 at 10:56 AM, Ryan Leavengood <leavengood@gmail.com> wrote:
Actually regarding the 42,000 changesets: these have all come in the last year and a half (!!!!), and are almost as many changesets as ever came before in the current WebKit repo. This is exponential growth! How is a small port possibly suppose to stay up-to-date under those conditions? Of course this just means that WebKit is a vibrant project and you cannot be faulted for that, but I think with this onslaught of changes it may be time to reconsider past methods of keeping ports up-to-date. Adam tells me Google has two full-time engineers keeping the Chromium port up-to-date. I think there is room for improvement in this area.
As far as keeping ports up-to-date goes, it seems like (in my limited experience) there's roughly four kinds of changes you have to work about: changes to tests that require new baselines, changes to the build system (adding, renaming, deleting files), changes to platform-specific core functionality (usually o/s-specific hooks), and changes to platform functionality (e.g., webaudio). Hopefully we will start writing more and more tests as reftests, to address the first category. Moving to one of the existing cross-port build mechanisms like GYP or CMake would help. Changes to core platform code in the third category are hopefully pretty rare, and I think you're just out of luck for the fourth category, but hopefully they're done in a modular manner and at least easy to enable/disable for a while. I think the more feedback we can get on what sorts of things you do have to do to keep up to date, the better things will get. -- Dirk
On Fri, Nov 4, 2011 at 5:40 PM, Dirk Pranke <dpranke@chromium.org> wrote:
Hopefully we will start writing more and more tests as reftests, to address the first category. Moving to one of the existing cross-port build mechanisms like GYP or CMake would help.
Yeah I will attempt to make use of GYP myself for the Haiku port, except I'll need to add a new backend to generate Jamfiles, since Jam is the preferred Haiku build system.
Changes to core platform code in the third category are hopefully pretty rare, and I think you're just out of luck for the fourth category, but hopefully they're done in a modular manner and at least easy to enable/disable for a while.
I think the more feedback we can get on what sorts of things you do have to do to keep up to date, the better things will get.
For additions to platform, I think a harmless default implementation should suffice. Having to add an empty method to a port just to satisfy the compiler seems like a lot of trouble. I can't find a good example at the moment, so maybe it really isn't an issue. Looking over some of the changes made to the Haiku port by non-Haiku people just shows a lot of renames and changing of method arguments and return values in the platform directory. This tells me that platform really isn't any sort of API (and yes I know it isn't meant to be) but maybe it should be? I personally would like to see WebCore evolve into being as self-contained as possible, with clear APIs for a platform to attach to. Maybe the new Platform directory will be the start of this, and if so, I applaud the effort. Right now the platform coupling is pretty bad. I hope one day #if PLATFORM(X) doesn't exist in WebCore, at least not where such code adds a class member or methods to core platform classes. -- Regards, Ryan
On Fri, Nov 4, 2011 at 3:04 PM, Ryan Leavengood <leavengood@gmail.com>wrote:
I personally would like to see WebCore evolve into being as self-contained as possible, with clear APIs for a platform to attach to.
I suspect the pain hasn't been big enough so far for any person/organization to decide to address this. You do sound enthusiastic about it though, and I suspect there would be people willing to review these changes as long as they didn't slow down WebKit or make it harder to maintain. dave
On Fri, Nov 4, 2011 at 6:12 PM, David Levin <levin@chromium.org> wrote:
I suspect the pain hasn't been big enough so far for any person/organization to decide to address this.
Well it may not really be worth the trouble, I just always found the #ifdefs in WebCore/platform to be a little smelly. But they work.
You do sound enthusiastic about it though, and I suspect there would be people willing to review these changes as long as they didn't slow down WebKit or make it harder to maintain.
That is good to know. There may be a time when I do this work, but I have bigger fish to fry at the moment with updating the Haiku port in our own repo, and my open source time is fairly limited currently (in case it isn't obvious since it took a month and a half to notice our port was removed from WebKit.) -- Regards, Ryan
On Fri, Nov 4, 2011 at 6:37 PM, David Levin <levin@chromium.org> wrote:
Exactly :)
What are you saying, the rest of the WebKit community doesn't want to spend weeks perfecting the architecture to make my life easier? :) When the need comes, it'll be done. Which may be never, but that's life. -- Regards, Ryan
participants (9)
-
Adam Barth
-
David Levin
-
Dirk Pranke
-
Eric Seidel
-
Geoffrey Garen
-
Peter Kasting
-
Ryan Leavengood
-
Ryosuke Niwa
-
Xan Lopez