Lennart Poettering [2015-05-27 11:42 +0200]: > Well, but let's not forget that a major part of the issues popping up > actually were committed weeks ago.
Actually, no. As I said, on May 11 most everything was working just fine, the udev regressions landed very late. The path_is_mount_point() regression landed much earlier, but is much less visible (and now there are tests cases with the patch I sent). > Things like the broken gperf generated bits or the missing EFI dirs > were in git since a loooong time. > > It would be great if downstream could help us with testing many of the > build combinations, at any time of the cycle, not just when it comes > to a release. Agreed. The "broken tarball" issues are not visible when building from git (which is what I'm doing all the time). We didn't have that kind of issues with 219 or 218 (or at least only negligible ones), but 220 taught us all that we need to test "make dist" builds more often. So we have two indepenent things to fix: * Regularly test "make dist", as nobody does that during regular development. Alternative: Stop shipping "make dist" tarballs altogether and just tar the tagged git snapshot. Given the amount of patching that most distros do, we pretty much all run autoreconf anyway (including Fedora), so not having the pre-generated autoconfiscation and pre-built manpages etc. in the tarball isn't actually that much of a deal. * Impose a release freeze period with announcing an impending release, distros do a deep testing (this is a day's work for me, so can't happen that often). During that time (which really shouldn't be more than a few days) we really should avoid any commit which isn't an important bug fix, especially not large refactorings or new features. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list email@example.com http://lists.freedesktop.org/mailman/listinfo/systemd-devel