Note on 'systemd-216-9'

[Adam Williamson]

On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote:

> I understand that systemd git is not easy to follow, but I don't think
> this differes that much from other fast-changing projects. If you take
> a random kernel release, it's not like there's a nice lwn-style description
> somewhere.

But there are actual releases. There's a kernel 3.17.1, and a kernel
3.17.2. They are artifacts with some sort of concrete presence, an
announcement mail and a changelog (even though yes, it's just a git
commit log). People can discuss the artifact called '3.17.1', say 'oh
hey that's broken in 3.17.1', whatever. There's no 'systemd 216.1' to
discuss, there's just a git branch which keeps changing. Sure, any
specific checkout of a git branch has superior capabilities to any
tarball and you can make one from the other, but the point of there
being a tarball called '3.17.1' is that *that's the thing that's
3.17.1*. A git branch that keeps changing is a very slippery thing to
try and do testing or communication or whatever in relation to.

The Fedora kernel maintainers maintain a clear distinction between
upstream and downstream 'hats'; we don't just have kernel 3.17-1, kernel
3.17-2, kernel 3.17-3, kernel 3.17-4 with changes from an upstream git
branch rolling in continuously, the upstream kernel releases are the
downstream package versions and the package releases are downstream
changes. The kernel package usually respects Fedora milestone freezes
very well, it's maintained in such a way that blocker/FE-fixing changes
can be isolated properly from other changes.

The kernel maintainers also decide a long time in advance what kernel
we're going to have in a Fedora release and stick to that. For F21 we
decided quite late to pull in 3.17 instead of 3.16, but the kernel
maintainers actively went out and talked to other groups (including QA)
about that, and made sure that everyone was on the same page about it
getting pulled in. (3.17 landed in stable on 10-12).

> [snip]
> 
> > checkout of the 216-stable tree we bump the package release but when we
> > add a downstream specific change we...bump the package release.
> Well, there's really very little difference between upstream and downstream
> here. stable/v216-stable is updated when I add patches to the Fedora package.
> If they were both versioned, the version numbers would be pretty much the same
> anyway.

But stable/v216-stable is *also* updated when you backport a whole bunch
of changes from upstream master, or whatever. Again, to you this all
feels like part of one process, but I'm not sure it really should be,
especially for a very significant project like systemd. For me, upstream
stable branches of something like systemd shouldn't really be intimately
associated with the Fedora package of that same branch. The upstream
stable branch should be maintained as a thing *in itself*, an object
with a clear raison d'etre and maintenance policy and so on, and the
Fedora package of that branch should be a separate thing. It shouldn't
'naturally' be the case that all these changes get sort of rolled
together into the same big blob of code which exists as both an upstream
git branch and a Fedora package which is a very direct reflection of
that git branch, with all the same stuff landing in both at the same
time.

There are usually different constraints on upstream and downstream at
different times; systemd isn't in a release freeze when Fedora is, for
instance. Maybe it makes sense for change (X) to land on the upstream
stable branch right now, but Fedora just wants blocker fix (Y). The
current process doesn't really seem to handle that kind of thing very
well, and it's exactly the kind of thing we have this distinction
between upstream and downstream maintenance for.

> > One simple change that might help a bit right now is to follow the
> > Fedora package versioning convention for when your package is built from
> > SCM snapshots:
> > 
> > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
> > 
> > So the systemd package should not just be 'systemd-216-8', or whatever,
> > but something like:
> > 
> > systemd-216-8.20141104gitaf59039bc
> Yes, this makes sense when building from upstream git, where the date
> and the number correspond to something tangible. Here the list of
> patches is somewhat arbitrary: patches are backported if they are easy,
> or when they fix know problems. They often end up not in the same
> order as upstream, for example where a cleanup patch is much later
> cherry-picked to avoid diff conflicts in an actual patch that fixes
> something. So the upstream git hash (or date) would be very misleading.
> 
> What I can do, and what should be useful, is to add tags to the stable
> branches where fedora releases are built from. 

I'm not sure if you're suggesting having tags on the *upstream* git repo
that reflect *downstream* package builds, but that seems like more
confusion between two separate processes to me - I'm suggesting more
separation between the two, not more conflation.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net