ECO

Engineering Change Order

This could be best understood as an approval for late Feature request against SUSE Linux Enterprise and therefore about ~4000/~12000 openSUSE Leap packages as well. This gets even more obvious and important by adoption of a following proposal Portal:Leap/FAQ/ClosingTheLeapGap.

Late Feature means that request is planned to be executed/implemented in a post-development phase of given release, this includes maintenance updates. Example of target milestone for given feature which would be treated as a Late Feature request would be Public Beta, Release Candidate, GMC, GM, Maintenance update.

Why

SUSE Linux Enterprise promises stability and predictability to customers, as in no changes in ABI, API or configuration during the lifetime of a service pack ... So "no surprises" when applying updates.

Any kind of derivation from the stability promise need to go through a change management process, e.g. the ECO process, with clear determination of need, risk and what will change how.

How this is done

Current process implementation happens in internal SUSE JIRA.

It's essentially a request for an approval from all stakeholders (Engineering, L3, Security, Maintenance, QA (in fact mostly Maintenance QA), documentation and Legal team.

A Feature request will not be implemented in given Service Pack unless it has an approval from all of previously mentioned stakeholders. ECO process can be generally avoided if request is submitted early in the development phase. Which is the preferred scenario for all features as introducing features late in the release introduces some risks.

Rejecting ECO does not mean that feature itself is rejected, it only means that it will not be implemented as a late feature request in given Service Pack.

Community involvement

This change process can also be used for features coming from Leap, but in this case would need a project management sponsor inside SUSE. Reach out to the Release Manager of Leap (Lubos) for help.