Define standard workflows for packaging and release engineering

My personal experience so far this year, has been that it isn't clearly documented anywhere how to help out with packaging or release engineering, and a lot of the processes are opaque (at least to me).

I would like for Chakra to make as much use of GitLab and its Merge Requests feature as possible, since it enables Quality Assurance (testing) in a manner that facilitates reviewing, discussing, assigning, and finally resolving the related issue. See chakra/packages/desktop#147 (closed) for an example of how (1) an issue is created, (2) a merge request is created from it, (3) a fix is committed and pushed, (4) the merge request is reviewed and approved, and (5) the change is finally merged, with the package being deployed to the stable repositories, and the issue is closed. Having the package of a merge request uploaded to a testing repository, and the @testers review it, makes the vetting process a breeze compared to creating periodical topics on a different platform and trying to work in two systems in parallel. I recommend reading this article from the GitLab blog, about starting with issues and working from there.

I suggest that the potential solution of this issue (as well as #39, #33, and #5) is implemented as a document/web page served on www.chakralinux.org, describing what has been agreed upon.

When do we do things?

Chakra is supposed to use a "part-rolling" release schedule, where updates of Frameworks, Plasma, and Applications by KDE are rolling, whereas updates of Linux, systemd, Qt are periodical. My general gripe here is that there seems to be no complete list of what is and what is not rolling, as well as the lack of explanation as to when periodical updates will happen, and for what reason. Are the periodical updates carefully chosen, sometimes rushed, sometimes delayed, in order to meet certain expectations - or are they arbitrary and simply done when there is time?

How do we do things?

My impression is that we do not fully make use of the features offered by GitLab EE - primarily I'm talking about Issues, Epics, Milestones, Labels, Merge Requests, and Boards. While I initially was skeptic to using GitLab, I would now very much prefer to embrace it (almost) completely. I would personally find it a lot easier to know what currently needs doing if the creation of tickets were fulsome, and coupled with Epics (e.g. for groups of packages) and Milestones (for live media releases).

Suggested workflows

I have already suggested a basic way of keeping all the information in a single place, that would help in keeping track of progress and what to do. I'd like to propose that we discuss, refine, and adopt the following workflows (loosely based on "GitLab Flow").

Packaging

This applies to all projects in https://code.chakralinux.org/chakra/packages, assumes that (1) CI is enabled and working, (2) the master branch is the default and protected, (3) the project is already cloned, and you have the required access, including an API key. Keep your feature branches short-lived - the vast majority should take less than one (1) day of work.

An issue is created, $issue.
Create the feature branch by clicking the button "Create merge request" in the web interface, or:
```
$ git checkout -b $issue
```

Write code. Commit changes:

$ git commit -am "Update to version $new_version"

Push your changes to the origin:

$ git push origin update_to_$new_version

The package should be uploaded to [testing] by the CI, allowing for @testers (https://code.chakralinux.org/testers) test the package and review the Merge Request. There are other ways of defining groups to review merge requests. If two (2) or more report it as working, the changes can be merged into the master branch, which should also automatically close the issue (if there is one) as well as upload the package to the stable repository.

Release engineering

The goal would be to make a release after every Plasma 5 release, three times a year.

Milestone (group Chakra) is created with the title "$CODENAME", start date and due date four weeks after Plasma
1. Epic (group Chakra) is created for the alpha "$CODENAME alpha"
  1. Make initial alpha version available, i.e. alpha1
  2. Comment:
```
/cc @testers
/label ~"Needs testing"
/due in 7 days
```
  3. @testers comment on the epic itself, and create new issues in the relevant projects If it works, comment:
    
    Tested and confirmed to be working.
    
    Other @testers who find it to be working as well respond with a 👍 on above comment
  4. Related issues are added to the epic
  5. Make new alpha versions available as necessary, e.g. alpha2, alpha3, etc.
  6. Close Epic once related issues are closed
  7. Rename final alphaX to beta1.
2. Epic (group Chakra) is set for the beta "$CODENAME beta"
  1. Comment:
```
/cc @testers
/label ~"Needs testing"
/due in 7 days
```
  2. @testers comment on the epic itself, and create new issues in the relevant projects If it works, comment:
    
    Tested and confirmed to be working.
    
    Other @testers who find it to be working as well respond with a 👍 on above comment
  3. Related issues are added to the epic
  4. Make new beta versions available as necessary, e.g. beta2, beta3, etc.
  5. Close Epic once related issues are closed
  6. Rename final betaX to rc1.
3. Epic (group Chakra) is set for the release candidate "$CODENAME release candidate"
  1. Comment:
```
/cc @testers
/label ~"Needs testing"
/due in 7 days
```
  2. @testers comment on the epic itself, and create new issues in the relevant projects If it works, comment:
    
    Tested and confirmed to be working.
    
    Other @testers who find it to be working as well respond with a 👍 on above comment
  3. Related issues are added to the epic
  4. Make new release candidate versions available as necessary, e.g. rc2, rc3, etc.
  5. Close Epic once related issues are closed
  6. Rename final rcX to the proper release name?
4. Epic (group Chakra) is set for the release "$CODENAME release"
  1. Upload to rsync.chakralinux.org
  2. Do the bittorrent thing
  3. Update www.chakralinux.org (separate issue and commit)
  4. Close Epic once related issues are closed
Close Milestone.

Website (Mélange)

This should be nearly identical to the workflow for packaging. Again, keep your feature branches short-lived - the vast majority should take less than one (1) day of work.

An issue is created, $issue.
Create the feature branch by clicking the button "Create merge request" in the web interface, or:
```
$ git checkout -b $issue
```

Write code. Commit changes:

$ git commit -am "Update to version $new_version"

Push your changes to the origin:

$ git push origin update_to_$new_version

This should make a preview of the changes available by using Review Apps, which is not yet enabled. If two (2) or more of our "core contributors" accept the merge request, the changes can be merged into the master branch, which should also automatically close the issue (if there is one). Then, make a deployment to the production environment.

Edited Jun 25, 2019 by totte