From dcd4d53df39b2500e19ad67b323fd90972046d94 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher <sgallagh@redhat.com>
Date: Mar 11 2019 12:29:29 +0000
Subject: Rewrite EOL lifecycle


Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>

---

diff --git a/lifecycles-upgrades-ownership/lifecycles-general.md b/lifecycles-upgrades-ownership/lifecycles-general.md
index 6f60746..4658893 100644
--- a/lifecycles-upgrades-ownership/lifecycles-general.md
+++ b/lifecycles-upgrades-ownership/lifecycles-general.md
@@ -6,44 +6,35 @@ There is a related [module lifecycle discussion](https://pagure.io/modularity/is
 
 ## Proposal
 
-I propose that a module lifeycle is defined as an EOL (end of life) information mapping to a specific Fedora release, with two special cases for "just keep building until I say otherwise" and "do not build".
+I propose that a module lifeycle is defined as an EOL (end-of-life) information mapping to a specific Fedora release, with two special cases for "just keep building until I say otherwise" and "do not build".
 
-Each module stream will have such information defined for Fedora and EPEL releases separately.
-Separation of these two is necessary as their EOL are not aligned, and I want to prevent module streams reaching their EOL mid-release.
+This information is defined separately for each module stream in the Fedora and EPEL projects.
+Separation of the data is necessary as the EOL dates of Fedora and EPEL are not aligned. Module streams reach their EOL dates at the end of a release cycle for each project.
 
-### The format
+### The required data
 
-The format could look similar to the following pseudo-syntax:
+For each module stream, end-of-life information **MUST** be represented as one of the following:
 
-A specific syntax is considered an implementation detail as far as this proposal goes, however, I'll be using following pseudo-syntax for demonstration purposes:
+* A specific Fedora release or EPEL minor release that identifies the **last** release that will carry this stream. For example, if Fedora 29 is shipping with pizza-module:horrible but it will not be included in Fedora 31 or later, the correct identifier is `f30`. Similarly, if mushroom-module:horrible is available on EPEL 8.0 but will not be included in EPEL 8.2 or later, the correct identifier is `epel8.1`.
+* If a stream is not intended for *any* release of Fedora (such as an EPEL-only module stream) or EPEL (a Fedora-only module stream), the correct identifier is `0`, which represents "do not build".
+* If no EOL value is provided for Fedora or EPEL, this means that there is no established end-of-life date at this time. This is to be interpreted as "always build". This is useful for streams that have no determinable EOL date, such as rolling releases or simple, stable tools that don't have a history of changing often.
 
-```
-module:stream EOL:
- - fedora: <value>
- - epel: <value>
-```
-
-... where `<value>` can be one of the following:
-
-* `f29`, `f30`, etc. to represent a Fedora release.
-* `epel8` to represent an EPEL release. There might be additional values introduced, such as `epel8.1` in the future.
-* `0` to represent "do not build".
+This default of "always build" is chosen to create minimal friction for packagers: they don't need to know and set an EOL date as part of initial module creation.
 
-Not specifying an EOL implicitly means "just keep building until I say otherwise". This is to make the initial friction in packaging as low as possible.
+Once set, these values may be extended (enabling support on later releases), but may not be shortened.
 
 ### Storing the information
 
-The information will be stored in PDC or eventually FPDC (a database service replacing PDC).
+This information **MUST** be stored persistently and made available via a stable, published API at a well-known web address.
 
-The benefits of using a database as opposed to, for example, a file in a git repository, are:
+Some possible examples (non-exhaustive):
 
-* Easier consumable by other tools or services
-* Easier to migrate if changes in the schema happen
-* Better potential typo prevention
+* A RESTful API front-ending the PDC (Product Definition Center), its forthcoming replacement or any other persistant data storage.
+* A git repository whose directory structure emulates a RESTful API containing static JSON documents for the EOLs. Accessed via a git web front-end such as Pagure or GitWeb.
 
 ### The mechanics
 
-An EOL information will be always associated with a module stream. Package stream branches will inherit their EOL information based on the module streams they are being part of.
+EOL information is always associated with a module stream. Package stream branches inherit their EOL information based on the module streams they are being part of.
 
 In order for the buildsystem to know the target Fedora releases for each module build, it will evaluate:
 

