CI/source-git

source-git

Source-git is current code-name for work which covers multiple areas. In our world, source git is a repository with upstream sources and Fedora build recipes (spec files, downstream patches as additional commits). The repository contains git branches which track respective Fedora versions.

Mission statement

We are aiming for four things:

1. Bring upstream projects closer to Fedora.

2. Improve stability of Fedora rawhide.

3. Improve day-to-day tasks of packagers.

4. Automate pulling of new upstream releases into Fedora.

Interested? Please, read on!

What and why?

• Our intent is to bring downstream and upstream communities closer: provide feedback from downstream to upstream (e.g. "Hello \<upstream project Y>, your newest release doesn't work in Fedora rawhide, it breaks \<Z>, here is a link to logs."). All of this can be automated.

• One of the implications is that it's trivial to propose changes back to upstream or cherry-pick fixes from upstream to downstream.

• Fedora rawhide stability is on the menu now: only merge, build and compose components which integrate well with the rest of the operating system. No more broken composes or updates which break rest of the operating system.

• Developing in dist-git is cumbersome. Editing patch files and moving tarballs around is not fun. Why not working with the source code itself? With source git, you'll have an upstream repository and the dist-git content stuffed in a dedicated directory.

• Let's use modern development techniques such as pull requests, code review, modern git forges, automation and continuous integration. We have computers to do all the mundane tasks. Why we, as humans, should do such work?

• We want dist-git to be "a database of content in a release" rather a place to do actual work. On the other hand, you'll still be able to interact with dist-git the same way. We are not taking that away. Source git is meant to be the modern, better alternative.

• Automatically pull and validate new upstream releases. This can be a trivial thing to do, why should maintainers waste their times on work which can be automated.

Current status

Right now we are aiming for a proof of concept. Once it's done, we'll create a demo and present it at DevConf.cz.

We understand this page is pretty concise. Once we have more information to share (especially when the PoC is done), we'll update this wiki page. In the meantime, please check out the github repo for an up to date information.