# Changelog and Release field generation discussion - notes

Happened on: 2020-03-02
People present: pingou, nils, asaleh, clime, ngompa, mhroncok (1st half), mboddu

Three approaches discussed:
* [<#commits>.<#builds>%{?dist}](https://hackmd.io/lp-9tq-UQXKQA4G0PEQN3w#Approach-1-ltcommitsgtltbuildsgtdist)
* [Using [E]VR Information of Existing Builds](https://hackmd.io/lp-9tq-UQXKQA4G0PEQN3w#Approach-2-Using-EVR-Information-of-Existing-Builds)
* [Annotated tags pushed by maintainers](https://hackmd.io/kIje9yXTRdWITwP7cFK2pA#Annotated-tags-pushed-by-maintainers)

Raw notes: https://hackmd.io/n_2Pb7WkSam8tmunx0rNgQ?edit

## General notes and summaries

* Because the approach is opt-in, in the end we could have several implementations to opt-into
* For POC we want to focus on a *single* implementation, that would be useful to most people
* We want to ensure SRPMs are rebuildable, that means we need to be editing spec-file before SRPM creation in the build system
* clime has interesting proposal for a new macro setup outside of RPM we could integrate into the build system, that could be useful for more things down-the line, i.e. container image definitions
* for POC we might be able to go with something simpler
* We want to have local build and external build produce the same result
* i.e. fedpkg local and fedpkg build should result in the same rpms

### Changelog generation

* For production-ready method we would like to be able to edit changelog, while maintaining its history.
* For POC we are fine with
* having immutable/append only changelog
* having editable changelog but it would be possible to accidentally break history by careless edit
* There are only two viable options
* generating from git-tags
* having an external changelog-file

### Release field generation

* We still probably care about preserving the upgrade path
* The option to stop caring is still on the table
* Decision to stop caring would be more involved, requiring more community discussion and decision from FESCO
* we probably want to move %{?dist} from the end to the middle
* should help with preserving upgrade-path
* conforms to current guidelines
* doesn't break current workflow
* based Nils' test, naively moving the dist-tag in the front of everything else would evaluate the release as lower, so the actual change would be more involved, i.e. we would need to force epoch update. Adding the dist-tag in the middle (between version and release), is not a problem
* dist-tag probably could be considered super-epoch, but moving it to the front would break guidelines
* there are some packaged that don't have epoch, i.e. fedora-release, fedora-repos, we'd probably need to make it explicitly default to nil

### Ideas about best approach and runner-up

#### Clime

* Annotated tags, considering both ease of implementation (i.e. with adding preprocessing to koji) and ease of use (i.e. changing both koji and fedpkg)
* Is fine with other approaches (i.e. EVR from existing builds) as long these are either entirely git-based or entirely build system-based (not <#commits>.<#builds>%{?dist} because it mixes both systems)

#### Neal

* EVR from existing builds, because that is what I see and use in other build-systems and it doesn't rely on git, helping with some of the outside-of fedora workflows (i.e. downstream builds, porting packages to other distros)
* <#commits>.<#builds> is fine as long as we move the dist tag. We need to compile all of this into the SRPM on SRPM creation.

### Mohan

* Likes Climes approach
* Thinks Nils' is closer to what we do now