Re: Diagreement with pkgconfig removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux