On Wed, 27.05.15 11:52, Martin Pitt (martin.p...@ubuntu.com) wrote: > 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).
Sure, some of the udev breakage is more recent. But a good chunk of the other stuff (gperf, EFI, path_is_mount_point()) is much older, and some of it is easily visible... > 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. Well, no. I use "make distcheck" regularly during regular development, and that's how I generate the final tarball. However, "make distcheck" generates a tarball off the 220 git tree just fine, if you had all the options enabled on a modern Fedora, like I do. Again, this is about testing options and combinations that are not regularly covered by the core systemd developers. My release procedure involves not only doing "make distcheck", but also then building the result in Fedora's koji, which then also involves another "make check" run, as part of the RPM build process, on all architectures Fedora supports. Only after that I tag a new release. > 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. Well, while I sympathize with the idea, this is still not how most current distros work... Also, "make dist" worked fine as mentioned, hence altering this part of the release process will not improve anything, but instead make things even more sloppy... > * 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. How about this: please run automated tests if you have them in regular intervals, always tracking git. And a few days before a release I'll notify the mailing list. I really don't want to drown development in "deep freeze" phases, that are then alternated with "crazy merge time" phases. Instead, I'd much rather increase the release frequency, keep a steady stream of changes, and ask downstreams for more help with testing and keeping git constantly in a releasable state. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list firstname.lastname@example.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel