| ... | ... | @@ -2,20 +2,25 @@ |
|
|
|
|
|
|
|
ELT Platform 24 - Retrospection
|
|
|
|
===============================
|
|
|
|
Work on ELT Platform 24 give us real-life feedback on initial version of ELT Platform's lifecycle and usage of Open Build Service (OBS). Base on that experience a new version ELT Platform Lifecycle is proposed. Following weakness of the previous workflow were identified:
|
|
|
|
Work on ELT Platform 24 gives us real-life feedback on the initial version of ELT Platform's lifecycle and Open Build Service (OBS) usage. Based on the gained experience, there is a new ELT Platform Lifecycle proposal. The current workflow has the following weaknesses identified:
|
|
|
|
|
|
|
|
* Updates approvals have too many stakeholders.
|
|
|
|
* Putting an update into ELT Platform requires approval from too many parties. It makes the process
|
|
|
|
long, heavy and discourage developers for providing fixes via official channels.
|
|
|
|
* New workflow limits number of stakeholders to developers responsible for Public and CCS releases.
|
|
|
|
The hope is that less stakeholders can make decisions faster and process will be more agile.
|
|
|
|
* Three phases of software lifecycle: unstable, stabilizing and stable were not respected.
|
|
|
|
* TODO go more into details about Yearly and Release streams
|
|
|
|
* The incentive to have "own" branch/fork of Platform is too high.
|
|
|
|
* TODO go more into details about cost of maintaining own fork
|
|
|
|
* Putting an update into the ELT Platform requires approval from too many parties. It makes the process heavy and discourages developers from providing fixes via official channels.
|
|
|
|
* New workflow limits the number of stakeholders to developers responsible for Public and CCS releases.
|
|
|
|
The hope is that fewer stakeholders can make decisions faster, and the process will be more agile.
|
|
|
|
* Three phases of the software lifecycle: unstable, stabilizing, and stable are not implemented in practice.
|
|
|
|
* The idea behind introducing unstable, stabilizing, and stable phases was to gradually mature the ELT Plafrom and avoid braking changes in the late development phase.
|
|
|
|
* In practice, we went quickly from an active development phase of unstable code to an almost fixed release. As a result, ELT Platform 24 wasn't suitable for development once released to the public.
|
|
|
|
* The ad-hoc alternative Platform CCS fixes that gap.
|
|
|
|
* The new ELT Platform Lifecycle is trying to satisfy those needs with Yearly and Release Streams.
|
|
|
|
* Yearly Stream: relatively stable development environments with a relaxed update policy. That stream resembles Platform CCS. The main difference is that there is no party-owning Yearly Stream. Updates need to follow rules and don't need to be approved.
|
|
|
|
* Release Streams: are usually Yearly Stream branches and are further stabilized. They serve the purpose of stable environments delivered to consortia or for ECM testing. Stakeholders decide which updates are allowed.
|
|
|
|
* The incentive to have "own" branch/fork of the Platform is too high.
|
|
|
|
* Each extra branch of the ELT Platform has a maintenance cost.
|
|
|
|
* The new ELT Platform Lifecycle allows the creation of on-demand branches, but maintenance cost has to be covered by the requesting party.
|
|
|
|
* End Of Life Policy is not well defined.
|
|
|
|
* Platform/ECOS/DevEnv versioning is unclear and often mixed.
|
|
|
|
* Lack of easy accessible/editable release schedule produce frictions.
|
|
|
|
* Lack of easily accessible/editable release schedule produces friction.
|
|
|
|
|
|
|
|
|
|
|
|
ELT Platform Lifecycle
|
| ... | ... | |
