Note on 'systemd-216-9'

Tue Nov 4 21:39:00 UTC 2014

On Tue, Nov 04, 2014 at 12:48:36PM -0800, Adam Williamson wrote:
> On Tue, 2014-11-04 at 21:20 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote:
> > > On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote:
> > > > On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> > > > > systemd "216-9" is not built from 216 at all, it is in fact systemd-217
> > > > 
> > > >   Why the misleading version number?
> > > 
> > > There is a comment in the spec:
> > > 
> > > # This is really closer to 217 than to 216, and it is easier to revert a few
> > > # patches then to carry all the other patches after 216.
> > > 
> > > and a changelog note:
> > > 
> > > - Pull more changes from upstream, including post-217 bugfixes. This
> > >   is now a bastard mix of systemd-216 and systemd-217, with some of
> > >   the important changes in systemd 217 still reverted:
> > >     readahead removal, timedatectl change, fq_codel as default,
> > >     job timeouts for init and poweroff, multi-seat-x removal,
> > >     coredumps from watchdog timeouts.
> > > 
> > > For the record, systemd-216-8 had ~588 patches.
> > > 
> > > I think the intent is that 216-8 and 216-9 be more or less the same
> > > codebase but arrived at in different ways, but in practice there seems
> > > to be a noticeable difference.
> > > 
> > > The diff I came up with is:
> > > 
> > > https://www.happyassassin.net/temp/systemd-2168-2169.diff
> > This diffs autogenerated content.
> 
> There's a bit of stuff at the top that could have been trimmed out,
> sure, but I didn't want to spend *too* much time on it. It's not that
> much.
> 
> > It also contains a rename of functions to add mac_ prefixes to
> > selinux functions. And a rename to hashmap functions in preparation
> > of for implementation changes which were done post 217 (and are
> > not part of this update). 
> 
> None of which was communicated in the package changelog, or the update
> description. And remember, what you just wrote is gobbledegook to most
> of the people testing updates
Well, it is gobbledegook to everyone, it is a completely meaningless
internal change. It was done with a sed script, and if the tree still
compiles afterwards, then its OK. It blows up the diff. It also makes it
annoying to backport later patches because of trivial conflicts, which
is why I include it in the update.

>, they are not necessarily coders and do
> not necessarily know anything about systemd internals. They are folks
> volunteering to provide feedback on pre-release updates; even those who
> are also Fedora packagers are not necessarily coders, and those who are
> coders don't necessarily know systemd's design.
> 
> > It is also done without -M, so catches
> > some renames as significant changes.
> > 
> > I'm frankly puzzled about the point of this exercise.
> 
> Well, remember, I'm not a specialist. I'm just the QA monkey. I don't
> know the detailed ins and outs of every codebase in the distro, QA
> doesn't in general, we just try to test the bits. The more information
> is available about what those changes actually *are*, communicated in a
> style appropriate to the knowledge level of the folks doing the testing,
> the better that job is going to get done. I didn't inspect the diff in a
> huge degree of detail, I just was interested in how much difference
> there actually is between '216 stable plus 500+ patches' (216-5 / 216-8)
> and '217 minus some reversions (216-6 / 216-9), so I bashed at the trees
> for fifteen minutes trying to figure it out, and it looked like rather
> more difference than the update description and package changelog
> suggested, so I thought it would be a good idea to communicate that.
OK, let's not dwell on this. I don't think this is a useful measure
in any way.

> Again, one thing that could prevent us having to have this kind of
> discussion would be for systemd to have more
> sophisticated/heavier/whatever stable release management.
If you want me (or someone else) to provide better changelogs or
whatever, than I'm happy to discuss it, but a thread about a specific
update on test@ is hardly the place.

> The
> systemd-stable repo is a definite improvement on the previous approach,
> but it's still missing actual *release management*, when you say 'OK,
> we're going to release an actual thing that will be called systemd 216.1
> and we're going to put all these bits in it and we're going to write
> down what those are'.
If you look the diff you made, it NEWS file is accurate and lists
user-visible changes. I guess it should not say '217'.  This *is* a
good suggestion, in the future I'll make sure that the NEWS file says
that it pertains to the release.

> Right now if someone asks what systemd is in Fedora 21, what do we say?
> Well, we can say 'systemd-216 stable' and point to
> http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable ,
> but then they ask 'what's that?', and what do we say? Where is its
> existence described? It's not systemd-216. It's not systemd-217. It
> doesn't have a version, it doesn't have a tarball, it doesn't have a
> readme, it doesn't have a changelog. The NEWS file says "CHANGES WITH
> 217:", so it seems dangerous to assume that it accurately describes all
> the changes on the 216-stable branch and *only* those changes.
You have the git tree. I'm pretty certain that this is superior to a
tarball. You can trivially generate a tarball if you want to.

If you looks at the NEWS file, although it says 'CHANGES WITH 217' it
also says '[reverted in this update]' in a few places, which I think
suggests that it pertains to this update. I'll make sure to fix the
header in the future.

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.

[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.

> 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. This was available
by looking at the last patch in the srpm, but not convenient to look up.

Zbyszek