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