Re: [eclipse.org-planning-council] Simultaneous Release Brainstorming

[Pascal Rapicault <pascal@xxxxxxxxxxxx>]

> * Only one repository will be used that will be continuously updated. 
> A stable "latest" url will be used to allow the user to update 
> continuously.
        What is the retention policy applied for content at this url?

> * It would be possible to add, update and remove API on any release.
> Before deletion an announcement of the intention would be done a long 
> time before (1 year or 2 year) in order that the depending projects 
> have time to upgrade to the new API.
> * A nightly SimRel build should be running.
        What is the difference between this build and the 
Gerrit-triggered build?
        What is the content expected to be found in this build? Nightly 
content from upstream projects or Integration build ?
        Who is the audience for this build? What are the expectations?

What happens to EEP packages? When are they assembled?

> * How do we organize the verification & tests in order to evolve from 
> a by hand homologation to a more automatic one ? How do we implement 
> integration testing ? Do we automatically create something which 
> contains everything starting it and see how it is going on ? who would 
> be responsible for that ?
    Testing everything together is just meaningless, you end up with 
too much noise. Packages (assuming they are still built) are a much more 
meaningful starting point. The first way to "test" is to get everybody 
to constantly dog food on the latest package by updating from the 
nightly SimRel builds (assuming those contain the latest I builds of all 
projects).
    As for more automated integration testing, the first thing to 
ensure is that the individual features are still working. This could be 
done by running a subset (identified by the team owning a component) of 
the existing unit test in the context of the "package", or have the 
owning team develop specific tests for this. The second thing to test is 
the actual integration between components (e.g. a model compare when 
EGerrit is installed) for which things will likely need to be developed. 
IMO, for those the difficulty here will be in finding the places where 
the integration could lead to different behavior.