Community
Participate
Working Groups
The choice of Reference Platforms made by the Eclipse project has a significant impact on adopters and products built on top of Eclipse. Companies clearly prefer published Reference Platforms as per the project plan [1] over any other variants. Upstream Eclipse projects also often adopt the choice of Reference platforms from the Eclipse Platform team. This is typically because the Reference Platforms convey a promise of increased subject to testing and better support by the Platform team. In reality though, the amount of testing that a Reference Platform undergoes varies widely. Some Reference Platforms routinely run the nightly test suites at the Eclipse Project releng team's servers. Other Reference Platforms are contributed by 3rd parties with a promise to test or check. The point of contact for such contributed reference platforms is not publicly listed. In general, some questions that the Community has are currently unanswered, and should be addressed in a document about Reference Platforms: * What amount of testing / development is actually done on a particular reference Platform? * Who can propose a new reference platform, what's the process for proposing it, and how can a 3rd party contribute test results on a particular platform? * How to identify others in the Community who use / routinely test on any given "more esoteric" platform, such that experiences can be shared? * What is the process for obsoleting / retiring a reference platform, or moving it up to a new service level of e.g. the JVM? * What are the specific points in time when the list of reference platforms is updated in the project plan to be current with latest developments? (e.g.: Are reference platforms "frozen" as per RC1 of the yearly train?) One idea that came up during the Eclipse PMC calls was that each Reference Platform could be described and tracked by an individual bugzilla bug. The question with this proposed process, however, is what should be the granularity of these bugs (one bug per platform / per release train / per change? Master bug for the platform with dependent bugs for requested changes?) Another idea might be using the Wiki, since the information history is way less intersting than the overall state at any given moment in time. A single Wiki page with associated discussion page could be used for the Reference Platforms, with a snapshot of the page being relected in the project plan at fixed times. [1] http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments
Unfortunately, I cannot make most of the AC calls due to a standing conflict, so I apologize if I am out of bounds here. The idea of having lots of different reference platforms goes against the advantage of a reference platform. The advantage of a reference platform is that all "participants" use that single platform during development, then towards the end of the development effort, the breadth of support is added by porting to all the various supported platforms. This is pretty standard in software development: have one lead (reference) platform and then port to the others when it is finished. So, for example, if TPTP and BIRT are both using the same reference platform, then when TPTP has a problem with BIRT during Iteration 3, then it is quite easy for BIRT to support us. If, however, TPTP and BIRT are on wholly different platforms, then it will be harder for BIRT to support us. So, I think your list is not reference platforms, but "Suggested Supported Platforms" I would be all in favor of an actual reference platform.
Yes, the terminology perhaps doesn't match what others mean by "reference platform". In the Eclipse project plan, when we say "reference platform" it really does mean something like "supported platform". I.e., bugs reproducible on one of these platforms will generally take priority over bugs not reproducible on reference platforms.
(I've been trying to get some thoughts written down about reference platforms all week. I'll post them here by EOD, whatever shape their in.) (In reply to comment #1) > So, I think your list is not reference platforms, but "Suggested Supported > Platforms" > > I would be all in favor of an actual reference platform. > So the problem that we are actually trying to solve, is to be able to say with some confidence that Eclipse will run on a wide range of platforms. We have found over the years that there can be significant variations in behavior between VMs, between the same VM running on different operating systems, and certainly between different window systems. Given that, it's important for us to discover as early as possible in development, when one of those differences impacts our code. To do that, we pick a selection of platforms to refer to when developing and testing our code, and those are what we call reference platforms. Having *one* platform that we developed against just wouldn't solve the problem. I'm not really fussed about the name. "suggested supported platforms" might be ok, except the "supported-ness" isn't really part of the equation; what's important is that these platforms actually get used.
Ok, here's what I've got. It doesn't really address the focus of this bug directly, but it has some good background... First off, for the purposes of this discussion, a "platform" is a specific version of an operating system ("OS") (e.g. Mac OS X 10.5.6) + a specific version of a window system ("WS") + a specific version of a Java virtual machine ("VM") (e.g. IBM J2SE 5.0 SR6b). For the window system component, the specific version that is used is typically defined by what is made available with a particular version of the operating system (e.g. "the version of Cocoa that comes with Mac OS X 10.5.6"), but other combinations are possible, and in any case operating systems may support multiple window systems. ------------ The rules for being a reference platform have always been somewhat informal. The Eclipse Plan says "We focus our testing on a handful of popular combinations of operating system and Java Platform; these are our reference platforms". From the point of view of the Eclipse SDK, there are two sources of testing that are used to validate reference platforms: 1) Our test suites are run on the platform on an ongoing basis, and they succeed or fail in the same way as the other platforms (i.e. failures on all platforms indicated bugs in our code, not in the platform). 2) There is some set of users who are *actively* running Eclipse on that platform, where "actively" means both that they regularly use the Eclipse SDK (with whatever other plug-ins they need) for software development, and more importantly, that those users _report_bugs_ when they find them. Experience has shown that, of the two sources of testing, 2) is actually the critical one. The test suites, by and large, are designed to identify bugs in our own code; they do catch major failures on platforms, but do not do a good job of identifying subtle platform-specific issues (e.g. at the level of buttons being drawn so small that the label is clipped, etc.). What really makes it all work is that there are people out there who are using the platform every day, who *notice* those issues and can be trusted to report them. We do run our tests on a selection of the reference platforms, but hardware and resource constraints prevent us from running on all of them. For example, we aren't regularly running them on Solaris, HP-UX, or AIX; we've had people run them there for us in the past, and we do know people who *use* the platforms, but they definitely aren't getting the same level of attention as, say, Linux/GTK. Of course, finding problems isn't enough, they also need to be fixed. So part of being a reference platform is that there is a group within the community who has _committed_to_fixing_bugs_ that are specific to that platform. The thing that makes that interesting is that there are different reasons why segments of the community step up to support a particular platform. For the SDK developers, we try to develop using a selection of platforms that we think will have wide acceptance, but also ones that will "work most of the kinks out" (i.e. enough variation that we can be reasonably confident we aren't building in platform specific limitations). Most of the platforms on the current Eclipse Project plan are there for this reason, and the bug fixing commitment comes from all the Eclipse Project committers. For VM implementers (which includes IBM), what is interesting is having their VM listed as a reference platform on as many OS+WS combinations as possible. Typically, they will provide resources to run our test suites on a set of platforms they care about, and will use Eclipse-based tools to do their own Java development. They also fix bugs in their VM (and associated class libraries) that impact Eclipse, or at least help us find workarounds. The JRockit-based platforms on the plan are examples of this case, where developers from BEA provide the testing and bug fixing commitment. For OS implementers, what is important is having a running Eclipse for their OS. If the OS includes a Java VM, which is the case for Mac OS X, for example, that's the one that they would like to be a reference platform, and they may step up and run our tests on it. Either way, we hope they would fix problems in their OS that impact Eclipse, or at least help us find workarounds. Similarly for WS implementors, they would like Eclipse to run on that WS. So, I guess the capsule summary is this: If there is a particular VM+OS+WS platform that you care about, and you are running our tests on it, and you have a community of people that are using and reporting bugs on it regularly, *and* you are making sure that bugs that are specific to that platform are getting fixed, then that should be a reference platform.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
