[eclipse.org-architecture-council] [Bug 262907] New: Define and document

[bugzilla-daemon@xxxxxxxxxxx]

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 [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


-- 
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.