Re: [gentoo-dev] stabilizing libraries without testing reverse deps
On Wed, 2 Oct 2013 10:12:00 +1300 Kent Fredric kentfred...@gmail.com wrote: On 2 October 2013 08:51, Peter Stuge pe...@stuge.se wrote: I agree, but I think the problem is basically that many people consider it impossible for newer to ever be shitty. Even if they are intimately familiar with the details of a package upstream they may still not be capable of determining what is shitty in the context of a distribution. I guess most stabilization requesters as well as actual stabilizers are even less familiar with upstream details, so determining what is shitty and not is really hard.. :\ The other really annoying thing you have to consider, is that most people out there are using all (~ARCH) or all (ARCH) keywording, not a mix of the two. ^ This has the fun side effect of meaning packages that are (~ARCH) and have (ARCH) dependents, where the package that is currently (~ARCH) is pending stabilization, has likely had nobody test it at all except for arch testers. AFAIK this moot since users running testing are expected to expect breakage regardless of what the breakage is, as long as it caused by testing package. btw, I'm one of those running mixed stable/testing system and based on my limited experience I believe this is a rare scenario. So if you're relying on the presence of filed bugs to give some sort of coverage metric, you're going to be out of luck from time to time. For instance, that fun bug where stabilising a version of libraw broke the things depending upon it that were already stable. Its ironic really, thats essentially a hidden bug that exists as a result of having two tiers of testing. https://bugs.gentoo.org/show_bug.cgi?id=458516 I've been long wishing there was a FEATURE I could turn on that would just report installs to a database somewhere, showing success/fail/succcess+tests/fail+tests , with dependencies, useflags, and other relevant context, so you'd at least have a dataset of *success* rates, and you could do more heavy testing on things where there were fail results, or an absense of results. +1 CPAN has a comparable service that leverages end users reporting test runs on code while they install it, and some end users, given this power, go so out and set up mass automated testing boxes, the utility of which I find useful on a daily basis, because a user is far more likely to get an automated success/fail report sent to a server, and far *less* likely to want to set time aside to go through the rigmarole of filing a bug report. Some users are also inclined to just try a few versions either side, and never file a bug report, or try twiddling USE flags or disabling problematic FEATURES to find a version that works for them, and you may never see a bug report for that. An automated X combination failed report at very least lets you know a datapoint where a failure occurred. I'd be cautious about involving users in this as it very often happens to myself that something breaks, I get mad and then figure it was my own fault (eg. messing with cflags I shouldn't mess with) I'm not saying we should make any automated decision making *based* on those reports, but it would be far more useful to have a list of known failure cases up front than to ask a tester to try be lucky and find it by looking for it. ( After all, bugs often arise when you're not looking for them, as opposed to when you are, and some bugs, when looked for, vanish ) signature.asc Description: PGP signature
Re: [gentoo-dev] stabilizing libraries without testing reverse deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/02/2013 06:43 PM, yac wrote: So if you're relying on the presence of filed bugs to give some sort of coverage metric, you're going to be out of luck from time to time. For instance, that fun bug where stabilising a version of libraw broke the things depending upon it that were already stable. Its ironic really, thats essentially a hidden bug that exists as a result of having two tiers of testing. https://bugs.gentoo.org/show_bug.cgi?id=458516 I've been long wishing there was a FEATURE I could turn on that would just report installs to a database somewhere, showing success/fail/succcess+tests/fail+tests , with dependencies, useflags, and other relevant context, so you'd at least have a dataset of *success* rates, and you could do more heavy testing on things where there were fail results, or an absense of results. +1 yo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSTFimAAoJEFpvPKfnPDWzzqIH/2Sfn7fbNGmZxGWKDRKNPowQ 7FyUeMWtjZ/ghL9J7erp9f293QBh2iLzgsVGqij1++LPul6BAYaAqX3HcktB3zNJ 8AEjLh9ied1497EtXiCrQGmL35dg2kyvtnxfp8/OAxz80CaJKO+TQoGBnn8gjBQF 1kzeIJ02aWuU40143B0pQ2dS8vjD0tYViWxy6QQr7YUdAChtkSsbchnVUA0oqnX4 fQXXA1pfwyDqKpKereDM5PqrGWumhXhaEwEzoSUCm7ozIW0mtFxdMhBabFWcJFMK lcTNWKyMfRCzoWsAu31jSC/nYMyIDFnS1VCQCk10pb6rFVkEpaQtW1MSyjRdBkI= =/IqK -END PGP SIGNATURE-
Re: [gentoo-dev] stabilizing libraries without testing reverse deps
On 3 October 2013 05:43, yac y...@gentoo.org wrote: I'd be cautious about involving users in this as it very often happens to myself that something breaks, I get mad and then figure it was my own fault (eg. messing with cflags I shouldn't mess with) That does happen from time to time on the CPAN Testers network, the great thing about this is though, that there exists a test report, user err or not. And it is the job of the person who manually looks into bug reports to determine if they're a clear indication of a real bug being exhibited, or if its a user configuration problem. And if a CPAN Author wants, they can contact a sender and ask for more context if the CPAN author feels it relevant. This is basically an inversion of bug reporting mechanics in cases of trivial accidents user side that might otherwise simply not get reported, because it becomes the developers duty to follow up on a failed build if they think its relevant. Also, it helps with the bug reporting process, and helps users diagnose their own bugs, because they can, upon seeing a test/build failure, check the bug tracker *and* the report matrix, and see if other users are also exihibiting the failure, to help them get an idea of what is causing the failure, by comparing reported variables. Then, a user can say Oh look, see, there's a boat load of tests failing on x86 with only this specific USE flag, there's no open bug for that, so I'll open one, and give the maintainer a lot of context on what looks to be the problem by linking directly to a handful of failed reports. This, would also be incidentally convenient for that old ANSI Term Escape codes problem, because the report/log submission would be automated ( giving us full control over how reports are performed ), and we could have a custom interface for displaying such reports that handled any submitted escape codes graciously, decoupling us from needing to find a way to handle that problem in bugzilla. Just the unfortunate part here is there are no off-the-shelf products for this problem space, so somebody would have to develop one. -- Kent
[gentoo-dev] Re: Addition of systemd subprofiles
El mar, 01-10-2013 a las 21:10 +0200, Pacho Ramos escribió: Hello This comes from: https://bugs.gentoo.org/show_bug.cgi?id=481920 as we would like to set some saner (for systemd usage) defaults in a subprofile, that way people could switch to it to inherit the changes more easily). For now, it masks consolekit USE flag, enables systemd one and masks static-libs for virtual/udev and packages relying in that support to prevent people from getting cryptic blockers when trying to enable that USEs. You have an example for gnome and amd64 in: https://bugs.gentoo.org/show_bug.cgi?id=481920#c12 - It adds a profile/default/linux/amd64/13.0/desktop/gnome/systemd/ that simply inherits .. (to get desktop/gnome profile settings) and systemd target path to get additional settings - It adds profile/targets/systemd for putting our settings Thanks The idea was to add them in a week since the mail - = Oct 8th
