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