El vie, 19-10-2012 a las 14:51 -0300, Alexis Ballier escribió: > On Fri, 19 Oct 2012 19:21:52 +0200 > Pacho Ramos <[email protected]> wrote: > > [...] > > > What I am trying to say is that, if we agree latest eapi is > > technically better, we need to try to get it used when possible (I > > mean, when, for example, eclasses are ported) for a "QA" reasoning. > > i think we all agree that there are improvements in newer eapis. > > what about filling bugs, preferably with patches, when such > improvements are really needed ? like what was done for nuking > built_with_use. > > arguing to death if 'should use latest eapi' should become 'must use > latest eapi' will never get things done :) > >
Because it will add even more work, I mean: - I catch a package using and old eapi and, then, still not passing --disable-silent-rules option. => First problem, I need to notice that package, there are packages I simply won't notice because I don't merge them ever or, simply, I don't notice that option is not being used. - I need to report a bug per each package using old eapi => I would need to report a ton of bugs for bumping eapi that, probably, I could have directly bumped myself if I would be allowed to (I already do it in my maintained packages and maintainer-needed ones, but not for others as maybe their maintainers dislike...) - Maintainer need to check that bug and commit the change or reject the bump (in that case we would be blocked if maintainer doesn't bump it for some strange reason). There are also some devs really slow to reply. - This effort needs to be done again and again in the future with newer eapis, while could be "automatically" done on next bump by maintainer.
signature.asc
Description: This is a digitally signed message part
