Hello, On Sat, Jan 14, 2017 at 2:16 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Sat, 2017-01-14 at 19:35 +0000, Zbigniew Jędrzejewski-Szmek wrote: >> You argue that the change should be mostly painless, but without >> providing any details: why not rebuild a 10 or 100 or 1000 packages >> in a mock root with pkgconf-pkg-config? Even if there are some minor >> hiccups, at least we'll be able to estimate the effort for the whole >> archive in the "Upgrade impact" section. > > Yes! Exactly this. > > In general, I think we really need to be moving away from the 'suck it > and see' approach to distribution development, where we essentially > decide that something sounds like a good idea, then go 'welp, let's see > what happens', throw it in Rawhide, and watch it explode into a million > tiny pieces, then spend the next month putting the pieces back > together again. In general, this is something I agree with. This is why we do extensive testing of pkgconf to make sure that betting on pkgconf isn't really a "suck it and see" affair. We feel very strong about ensuring that we do not break distributions, and when we need to make changes that have higher risk of breakage, we usually provide an LTS branch to use while we sort out a plan for mitigating the breakage. This is what I believe responsible maintenance of a critical toolchain component to be, and is the maintenance strategy we have used for 5+ years of maintaining pkgconf as a pkg-config frontend. In general, we take QA very seriously so that distributions are confident in our releases. > Yes, we've done that before, and yes, we've muddled through. But we > really can do it better these days. We do have better tools and > somewhat more capacity in our systems. There *are* tools for doing > large-scale test builds like this. We *can* even build images from the > test koji tag or whatever and run some automated tests on them, to see > if they work. (If you want to do that, please, come talk to the QA team > about it; we'll help make it happen;it isn't a super-smooth fully- > automated process yet, but we *can* do it, and if it starts becoming a > regular thing, that gives us and the releng team a great motivation to > *make* it a smooth fully-automated process). We have better choices > than "just do it and see what happens". I think it might be good for > folks involved in the Change review process to start asking questions > like "how are we going to see whether this works at all before we land > it in Rawhide mainline?" when reviewing Changes like this in future. I can't really comment on this in regards to Fedora, but my understanding was this was the submitter's first change like this, so I suspect he just got a little ahead of himself. He has been in #pkgconf on IRC all day setting up a mass test build to verify that everything will be fine. If it were my change request, I would likely have collected that data first, but at least he is trying :) William _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
