[Avocado-devel] [RFC v4]: Long Term Stability (was Avocado maintainability and integration with avocado-vt)

[Cleber Rosa]

On 04/28/2017 11:17 AM, Jeff Nelson wrote:
> 
> 
> Maybe I'm being pedantic, but how about some visual separation between
> the sprint release and the things that follow? It looks to me as if
> one could interpret everything under a numbered sprint release as
> happening at the same time, when in fact we want to point out that
> (a) bug discovery can happen at any time
> (b) the bugfix occurs next
> (c) the severity of the defect determines the timing of the release
> (c.1) moderate and minor bugfixes to lts branches are held until the
>       next sprint release
> (c.2) critical bugs are released asynchronously, without waiting for the
>       next sprint release.
> 
> 53
>   * sprint release 53.0
> 
> * moderate bug that affects users of master, 52lts and 36lts is found
> * fix is added to master and backported to 52lts and 36lts
> 
> 54
>   * sprint release 54.0 **AND** 36lts release 36.5 **AND** 52lts release 52.1
> 
> * minor bug that affects users of master and 52lts is found
> * fix is added to master and backported to 52lts
> 
> 55
>   * sprint release 55.0 **AND** 52lts release 52.2
> 
> * critical bug is found that affects users of 52lts *only*
> * fix is made to 52lts and 52lts release 52.3 is immediately announced
> 
> I dunno; just something to think about.
> 
> -Jeff
> 

This is how I managed (I hope!) to accommodate your suggestions:

---

Timeline example
================

Consider the release numbers as date markers.  The bullet points
beneath them are information about the release itself or events that
can happen anytime between one release and the other.  Assume each
sprint is taking 3 weeks.

 36.0
   * **LTS** release (the only LTS release available at the time of
     writing)

 37.0 .. 49.0
   * sprint releases
   * 36.1 LTS release
   * 36.2 LTS release
   * 36.3 LTS release
   * 36.4 LTS release

 50.0
   * sprint release
   * start preparing a LTS release, so 51.0 will be a **beta LTS**

 51.0
   * sprint release
   * **beta LTS** release

 52.0
   * **LTS** release
   * 52lts branch is created
   * packages go into LTS repo
   * both **36.x LTS** and **52.x LTS** maintained from this point on

 53.0
   * sprint release
   * minor bug that affects 52.0 is found, fix gets added to master and
     52lts branches
   * bug does **not** affect 36.x LTS, so a backport is **not** added to
     the 36lts branch

 54.0
   * sprint release 54.0
   * LTS release 52.1
   * minor bug that also affects 52.x LTS and 36.x LTS is found, fix
     gets added to master, 52lts and 36lts branches

 55.0
   * sprint release
   * LTS release 36.5
   * LTS release 52.2
   * critical bug that affects 52.2 *only* is found, fix gets added to
     52lts and **52.3 LTS is immediately released**

 56.0
  * sprint release

 57.0
  * sprint release

 58.0
  * sprint release

 59.0
  * sprint release
  * EOL for **36.x LTS** (18 months since the release of 36.0), 36lts
    branch is frozen permanently.

A few points are worth taking notice here:

 * Multiple LTS releases can co-exist before EOL

 * Bug discovery can happen at any time

 * The bugfix occurs ASAP after its discovery

 * The severity of the defect determines the timing of the release

   - moderate and minor bugfixes to lts branches are held until the
     next sprint release

   - critical bugs are released asynchronously, without waiting for
     the next sprint release


---

Regards,

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170429/4ac6322b/attachment.sig>