please stabilise
https://bugs.gentoo.org/show_bug.cgi?id=530720 - what about this request?
David, you need to explain this stablereq a bit better than "please stabilise". qbittorrent-3.3.10 was added to the tree *minutes* ago. Are you not aware of the 30-day policy for stabilizations? If you need an exception, you should definitely explain why. The new ebuild seems to have major changes (the build system changed completely) compared to the current stable candidate (3.3.7)... and there's also bug 530720...
(In reply to Davide Pesavento from comment #2) > David, you need to explain this stablereq a bit better than "please > stabilise". qbittorrent-3.3.10 was added to the tree *minutes* ago. Are you > not aware of the 30-day policy for stabilizations? If you need an exception, > you should definitely explain why. The new ebuild seems to have major > changes (the build system changed completely) compared to the current stable > candidate (3.3.7)... and there's also bug 530720... Given that 99% of Stablereqs are purely compile checks, I don't really see major useability testing as an obstacle with stablereqs nowadays anymore (I've seen way too many stablereqs that went through fine, yet were not stable). I've tried all use flag combinations, and it worked fine me, the GUI seemed ok etc. I've tested it and it solves all the 3 outstanding bugs against qbittorrent + gets rid of Qt4 (now that upstream by default also prefers Qt5). You can close this if you like.
An automated check of this bug failed - repoman reported dependency errors (51 lines truncated): > dependency.bad net-p2p/qbittorrent/qbittorrent-3.3.10.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['>=net-libs/rb_libtorrent-1.0.6'] > dependency.bad net-p2p/qbittorrent/qbittorrent-3.3.10.ebuild: RDEPEND: amd64(default/linux/amd64/13.0) ['>=net-libs/rb_libtorrent-1.0.6'] > dependency.bad net-p2p/qbittorrent/qbittorrent-3.3.10.ebuild: DEPEND: amd64(default/linux/amd64/13.0/desktop) ['>=net-libs/rb_libtorrent-1.0.6']
(In reply to David Seifert from comment #3) > (In reply to Davide Pesavento from comment #2) > > David, you need to explain this stablereq a bit better than "please > > stabilise". qbittorrent-3.3.10 was added to the tree *minutes* ago. Are you > > not aware of the 30-day policy for stabilizations? If you need an exception, > > you should definitely explain why. The new ebuild seems to have major > > changes (the build system changed completely) compared to the current stable > > candidate (3.3.7)... and there's also bug 530720... > > Given that 99% of Stablereqs are purely compile checks, I don't really see > major useability testing as an obstacle with stablereqs nowadays anymore > (I've seen way too many stablereqs that went through fine, yet were not > stable). I've tried all use flag combinations, and it worked fine me, the > GUI seemed ok etc. > > I've tested it and it solves all the 3 outstanding bugs against qbittorrent > + gets rid of Qt4 (now that upstream by default also prefers Qt5). That's not the point. If there's a policy you should follow it (again, motivated exceptions such as security issues aside). If you don't like the policy, come up with a proposal to change it, don't simply ignore it.
If 3.3.11 fixes these issues - it has a big Changelog - maybe we can stabilise it instead of .10 and take the usual 30 day threshold with a grain of salt, in face of current stable qbittorrent being apparently broken.
@pesa, so bug 607734 looks wholly invalid and should not block this anymore. Can we simply replace 3.3.7 with 3.3.10 in bug 530720 to resolve this standoff?
(In reply to Andreas Sturmlechner from comment #7) > Can we simply replace 3.3.7 with 3.3.10 in bug 530720 to resolve this > standoff? Sounds good to me.
Stabilisation was completed in bug #530720.
