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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
