On Thu, Oct 09, 2008 at 11:34:59PM +0100, Ciaran McCreesh wrote: > On Thu, 9 Oct 2008 15:22:19 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > So where exactly is this "sky is falling" issue you're worried > > about? Bugs happen. > > It means anyone using EAPI 2 now is going to encounter severe > breakages with Pkgcore. Simply put, all your Pkgcore users are going to > get screwed over very messily as soon as they try to use any EAPI 2 > things. Is this not something we should be caring about?
You're massively overreacting, either due to ignorance or due to trying to stir things up. Tree currently has 308 ebuilds out of 25500 that are EAPI=2. ~1.1% of the tree. Of that 308, number of ebuilds that either inherit java-utils (which adds src_prepare), define their own src_prepare, or even *match* default via grepping in the ebuild is 20. I reiterate. 20 out of 308 EAPI2 consumers, meaning that pkgcore misbehaved on .078% of the tree (all unstable ebuilds in addition, and haven't even counted how many are masked), and it did this for a window of a few days. There is a difference between not caring about breakage, and gauging the affect of the breakage and dealing with it appropriately (triaging). Regardless, it's worth noting that 0.4.7.11 was cut, and commited to the tree (thank you zac) already fixing the issues you so kindly pointed out. So those 25 ebuilds pkgcore broke, are now addressed. Frankly I'd be amazed if anyone even spotted it yet (both portage and pkgcore) due to the minimal slice. > > Frankly you're overreacting on this- and that is assuming you *are* > > overreacting instead of just going for a bit of a public smear > > via bugs. > > Bah. If you want me to lecture you on how you're being blatantly > irresponsible and incompetent then I will do, although by the way you > rush on the defensive and start trying to cover your ass by throwing > accusations at me it looks like you already know it. But what I care > about is getting the mess fixed in the most painless way possible. s/painless/painful to targets/. And to be clear, just like the last time you reported bugs in pkgcore via ml, yes, there were bugs in EAPI2. No ass covering. Also, if you want to bitch at me and call me incompetent do it via your blog. No one this ml cares to watch us trade blows, let alone deal with personal BS that bleeds into your posts. > This is a real issue and developers need to know the implications. > > > Either way, my vote is fix the bugs, leave EAPI2 as is, and in the > > future kindly file bugs properly (preferably w/out the noise, but > > I'll take usable bug reports in almost any form). > > If you want bug reports via trac instead of IRC, get your trac to > respond faster. Actually trac is responsive. Now if you work your way into the trac-bzr bits (source browsing), yeah, it's slower then I'd like (patches welcome of course). Regardless, bugs.gentoo.org exists; if it's EAPI related, I'd expect folks wouldn't mind if a pkgcore bug or two wound up there (it's not like it's a feature request for pkgcore after all). Frankly, the sky is not falling. A max of 20 freaking ebuilds misbehaving for pkgcore (<20 for portage also) doesn't warrant mangling EAPI2 let alone going to the ml to stir up shit. In the future, kindly just file bugs. If upon investigation it is an issue, sure escalate it. Essentially focus on getting it straightened out instead of going for drama. ~brian
pgpcds9KNzHPR.pgp
Description: PGP signature
