Package maintenance in git - 21st century way

by Vaclav Tunka

Senior Software Engineer

Red Hat, JBoss EAP

Method from seventies/eightees/ ninetees

• Pristine tar.gz / tar.bz2 source maintained manually.
• Patches send as text files on ML.
• Review happening on ML.
• Using RCS, CVS, and tons of obscure systems; Commiter != author and other pains.
• Constant hell of regenerating tons of patches by maintainers

You can say "Fedora moved to git / dist-git already"

• Theoreticaly yes, in reality people are still using it like dist-CVS.
• And in the first place CVS was warped to Dist-CVS which it was never designed for (lookaside cache arch, etc.)
• The most difficult isn't to learn a new syntax / command but to adapt one's thought process.

You could ask what's wrong about that?

• TLDR - nearly everything.
• Biggest pain - manual archival of upstream (git) repo in a tar.gz as without .git metadata! Why?
• Archiving patches in git! Again..
• When rebase is done, half of the patches might not apply - maintaining granularity and manually! regenerating invidivual patches on top!
• Developer time is precious and we waste it on unfriendly, unproductive workflow (IMHO).

Method for 21st century

• Use dist-git only for META data:
  • "sources" flat file,
  • other configuration things,
  • etc.
• Use common set of scripts for various project versions.
• Maintain the component source code in a normal (non dist-* VCS system)
• Workflow on next page.

Maintenance git workflow

Method for 21st century

• Already used in most JBoss Community upstreams for years, in tons of other upstreams too.
• Using Pull/Merge Request workflow on top of git (or other distributed VCS).
• Upstream has liuetenants who have push access, everyone else submits pull requests - even if you had commit (push) rights 10 years ago, it does not matter, you need to sumbit PR - for a good reason, it's proper code review.
• Every pull request is safeguarded by CI (Travis, Jenkins, Teamcity, you name it).

What about RPMs

• Now everything is docker, docker, docker, but you might need to maintain good ol' RPMs. 
• Why not place a full git repository into the SRPM - automated tool can always generate .patch files from individual commits including proper naming & metadata?
• A policy question - set up proper git hooks to safeguard developers obey these rules.

So, when will we have this in Fedora?

Questions / Discussion time

Thanks for your attention, let's bring Fedora to 21st century.