Note on 'systemd-216-9'

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote:
> 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).
Lots of things you say I agree with. Yesterday after you complained
that there the releases are not tagged in dist-git, I actually went
ahead and added tags for all post-F20 releases (haven't pushed them
yet).

The subject of point releases hasn't come up before. Actually I
haven't had *any* communication about the stable branches since they
were created apart from a few patches backported by other systemd
maintainers. If there are difficiencies, I need to hear about them.
I love working on Fedora, and I'm happy to fix whatever I can.

Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I
pushed aggressively for an update in F21 to diminish this backlog a
little. Some of those bugs have fixes upstream, but because of the
large code reorganization that was done after systemd-208, lots of
patches can't be really backported and would have to be rewritten to
apply to the version of systemd that is in F20. This situation is
something that I want to avoid as long as possible in F21, and that is
why pre-release F21 updates were following upstream closely.

I'm sorry about the timeout bug #1154768, it was my fault that it
landed in an update. We (upstream) knew about the issue, but I don't
think that anyone saw it as more than an annoyance, and that is why it
slipped through. Like I wrote before, that update *was* supposed to go
stable before the alpha freeze, and was supposed to go through all the
testing sufficiently early.

> > 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.
I update the stable branches when I work on a Fedora update. So I'll just
tag the stable branch at the time when it is pulled into a Fedora update.
The process will not change in any way from what happens currently, but
there'll be a visible tag.

Zbyszek