|[eclipse.org-architecture-council] [Bug 262907] New: Define and document a process for Reference Platforms|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262907 Product/Component: Platform / Website Summary: Define and document a process for Reference Platforms Product: Platform Version: 3.5 Platform: PC URL: http://www.eclipse.org/projects/project- plan.php?projectid=eclipse#target_environments OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: Website AssignedTo: Mike_Wilson@xxxxxxxxxx ReportedBy: martin.oberhuber@xxxxxxxxxxxxx CC: eclipse.org-architecture-council@xxxxxxxxxxx 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  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.  http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Back to the top