From: "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] cmake-utils.eclass and bug 475502
Date: Wed, 17 Jul 2013 17:42:32 -0400 [thread overview]
Message-ID: <51E70FC8.90704@gentoo.org> (raw)
In-Reply-To: <51E70DEC.3060506@gentoo.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/17/2013 05:34 PM, hasufell wrote:
> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>>> On 07/17/2013 04:57 PM, hasufell wrote:
>>>> I know there was an announcement about the upcoming change to
>>>> cmake-utils.eclass, however... it is not enough to give a
>>>> deadline without caring if people actually fixed it by then.
>
>>>> By doing that you risk breaking stable packages which is not
>>>> trivial.
>
>>>> You _must_ do a tinderbox run, test that stuff in an overlay or
>>>> whatever. You are responsible for ALL reverse deps.
>
>>>> The way it was done... was not appropriate. Please be more
>>>> careful next time. There are still incoming bugs about broken
>>>> base_src_* calls. (see the tracker)
>
>
>>> I discussed this with hasufell on IRC, but I'll lay out the
>>> response on the list too. Yes, this was my fault. We (KDE team)
>>> tested in our overlay, but none of the packages there use the
>>> base_src_* calls, which is why it didn't come up in testing, and
>>> I did not realize that there were packages that did rely on the
>>> implicit base inherit to call base_src_* directly.
>
>> ...and that is why it isn't permitted to directly use an eclass
>> that you don't inherit. While I agree testing could (should) have
>> been better, the fact that people ignore the rules for writing
>> ebuilds shouldn't entirely fall on the KDE team.
>
>
> It doesn't matter in the slightest whos fault it is or who should be
> blamed.
>
> It is about maintaining stability for the user. Especially when it
> comes to stable ebuilds.
>
> That means the methods for eclass changes must be more thoroughly.
>
I completely agree with you, the changes should have been tested better.
The ebuilds with these errors popping up ALSO should have been tested
better. Considering this is a QA violation, perhaps it is possible to
add a check in repoman for using something from an eclass which you
didn't inherit. I doubt the slowdown would be horrible and clearly it
would catch a huge number of QA violations.
I'm not saying this isn't bad, I'm not saying KDE team didn't mess up,
I'm saying a lot of people messed up and the not well enough tested
eclass change found a lot of QA violations which should have been caught
much earlier.
- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR5w/IAAoJEKXdFCfdEflKUQ4P/24f/wkmQHCFskq2P+b8xgpY
PpRkE4XV/AV4oYRFWJ0HNmPcx1gqNVHdjED8yhQ8JqEPFJbgMWRMa1vfkY84Qkqb
b4CIDcmCd1A9jkdFtP6llgCSP/ub0cokB9O1Cb5kAZrDy+VzctB81x6X2uuUF53N
dcoVEga4gqZf5W4RBBE5R7yneB92K5bZjulQsPG22pAfWmKCoVUoaPOh4c104mXt
r+qMboTdHhfNldYdTykKQy5wSMERpKxzPBw9sG3ON96qajSD9nnmVzCVmWZrixfG
WJWf2G5RhLoIjjGPR0d9wUp5w212W7E6OVIpbeye5nX/YpePEYL4YAboAPbBs9Ws
XRWJOpy+/+W4Wr7J+pic41S96w2r31kBoXRpR6+Qrn+JZAaWbRBMadqVhHnYJx+w
cxOFhpKnJRF7l0t76wRevUMoD4aMRi3ZqEjH6SdqIJ9QHq40k6fITrmahq5k8Y24
TZOsGVpGi1XhrjrSfNXnVy9Dstjf5D6W39nzYQI+AaXURynV276fb/BPABHdoRuR
4eITAA6vIQ6rxoTAsOjmy+w2ySOzJkEVK0WrrcaJJAxhu1+ztjmcaq9d5kO7mdIt
5iyEcgNielhrf7wkpe+yM0SwhE5h1/+znhMRgxMAwuktWxK43KMBV39G28b9XMb6
LjG8NvQO4K4LGeNOhWAA
=elf2
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-07-17 21:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 20:57 [gentoo-dev] cmake-utils.eclass and bug 475502 hasufell
2013-07-17 21:17 ` Chris Reffett
2013-07-17 21:28 ` Rick "Zero_Chaos" Farina
2013-07-17 21:34 ` hasufell
2013-07-17 21:42 ` Rick "Zero_Chaos" Farina [this message]
2013-07-17 21:47 ` hasufell
2013-07-17 21:55 ` Rick "Zero_Chaos" Farina
2013-07-17 22:15 ` hasufell
2013-07-18 7:06 ` Michał Górny
2013-07-18 22:11 ` Zac Medico
2013-07-17 23:09 ` Tom Wijsman
2013-07-18 16:40 ` Alexis Ballier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E70FC8.90704@gentoo.org \
--to=zerochaos@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox