#2 Draft MVP workflow
Opened 3 years ago by ttomecek. Modified 3 years ago

In the MVP, we should aim for a simple, CLI workflow initially before ramping up with automation and CI - that should give us a great minimal target.


Metadata Update from @ngompa:
- Issue untagged with: accepted

3 years ago

Metadata Update from @ngompa:
- Issue tagged with: accepted

3 years ago

Of note from the minutes. Kernel is currently using scripts that sync src-git to dist-git. Of course that does require I check to make sure that no one pushed anything to dist-git before I push that needs to go into src-git. Ideally, I would love to get to the point where koji can build directly from src-git, and bypass dist-git all together. Anyway, the current scripts make an srpm in the src-git, do a dist-git checkout, delete everything, and explode the srpm to add it, uploading any relevant source tarballs required.

@jforbes, a few questions:
- Why does kernel use an srpm as an intermediate step when updating dist-git?
- Where is the archive generated from? From a source-git commit? If yes, how is parity with a upstream release ensured? Is this parity important? If not for kernel, would it be important for other packages?
- Does the srpm carry downstream patches as patches, separated from upstream code, or it's just a an archive of the source code with downstream patches included?

@jforbes, a few questions:
- Why does kernel use an srpm as an intermediate step when updating dist-git?

It is an easy verification that everything required to build, and nothing else, is put into dist-git. As dist-git only concerns itself with being able to build an rpm, it seems the best common carrier.

  • Where is the archive generated from? From a source-git commit? If yes, how is parity with a upstream release ensured? Is this parity important? If not for kernel, would it be important for other packages?

The kernel does generate it from a source-git commit, but we track both the upstream tree and the fedora/red hat tree. To keep with packaging guidelines, we make a tarball of the upstream commit we are based on, and generate a patch with the fedora additions to that tarball, which is applied by the spec. We also generate a patch list which lists the commit ids and summary for each patch included in that mega patch so that it is very easy to see exactly what is different between the Fedora package and the upstream tarball.

  • Does the srpm carry downstream patches as patches, separated from upstream code, or it's just a an archive of the source code with downstream patches included?

The srpm carries an upstream tarball and a single distro patch, with a patchlist that lists which individual commits are in that patch for easy digestion.

Log in to comment on this ticket.

Metadata
Boards 1
MVP Status: Backlog