[PROPOSAL] 'Experimental` branch for managing large-scale or complex changes

[petefoth]

Background

• This project is a 'live' project, currently used to make builds for over 200 devices evry month. We have to be very careful when making changes in the project that those changes do not 'break' the 'production' system (i.e. the image used in the monthly build run).
• Some changes have been proposed in the past that offered significant benefits but either
  • were not merged because the changes were so extensivie or complex that there was a real risk of 'breaking' the production system
  • were merged, but caused significant problems to avoid or correct 'breakages'
• This proposal suggest a process that can be used to allow such changes to be made and managed in a way that minimises the risk of breakages, and potential stress on change owners and project maintainers. It does impose a certain amount of 'extra' work on the owner / proposer / implementer of the change, and on the project maintainers. I hope this extra work will be enough to get changes implemented 'safely', but not too much to prevemt changes being made at all.

All Comments are welcome!

Proposal

• Create a new 'Experimental' branch to manage new / changed features - particularly features involving wide-ranging ,large scale and / or complex changes - which may or may not get merged into 'Production' (i.e. master branch)

• To avoid duplication of effort or incompatible / conflicting changes, the changes

  • should be proposed, and the proposal discussed and agreed, preferably before starting work
  • should be done in a dedicated branch (based on the the current 'experimental' branch)
  • should be submitted in a draft Pull Request for review, discussion and modification. The PR should include evidence of extensive testing, including use of the proposed change
    • to make builds for at least two devices in each LOS branch currently supported officially (currently 18.1, ``19.1,20.0`)
    • to make builds for at least one device in the most recent unsupported branch (currently 17.1)
  • will be 'owned' by a single developer, who will be responsible for making and testing the changes, and creating the necessary PRs

• Changes to 'Production' will not be made often: no more than two or three times per year. Once merged to the 'Experimental' branch, changes that are intended for inclusion in the 'Production' branch, will be submitted as PRs to a 'Staging' branch. Before being merged to 'Production', the 'Staging' branch. will be tested by

  • using it in a test build run on the build server, run in the two week 'gap' between montlyh build runs, for a small number of devices (2-5?) for each officially supported branch.
  • possible using it instead of 'Production' in the next monthly buuld run

• Some examples of possible changes that might be handled in this way

  • Specifying arguments for calls to e.g. repo init or repo sync - see Adds option for shallow cloning #469 and [Feature] Option to skip repo sync #160 (and already done and merged add repo init args #431)
  • Making the necessary changes to support building for a new Android version e.g. Android U / LOS 21
  • Making some (long running) parts of the build 'skippable' - see [DRAFT] add REPO_SYNC to disable repo sync #432 and [Feature] Option to skip repo sync #160
  • Adding support for building additional different Lineage OS-based OSes e.g. Lineageos / LineageOS 4 MicroG using LineageOS-UL repos instead of LineagOS repos, IodéOS, /e/OS

  (The last two are changes that I am currently spending time on)

• At the discretion of the maintainers, changes to production which are small scale, self-contained and easily verifiable, may not be required to use the 'Experimental' branch, although they should follow the outline of this process (proposal, implemenation, test, PR from owner, merged by maintainers)