Re: [gentoo-dev] Automatic testing on Gentoo
On 05/10/2011 03:13 PM, Jorge Manuel B. S. Vicetto wrote: So, why more testing? For starters, more *automatic* testing. Then more testing as reports from testing can help greatly in identifying when things break and why they break. As someone that looks over the automatic stage building for amd64 and x86, and that has to talk to teams / developers when things break, having more, more in depth and regular automatic testing would help my (releng) job. While I agree whole-heartedly with the sentiment being expressed here, I just want to point out and remind everyone that automated testing is no substitute for real live people using (and breaking) things. People are remarkably inventive and creative when it comes to finding ways to break things in ways that the developers never even considered. All I'm trying to say is that I've seen (and worked on) far too many teams in the past that fell into the trap of thinking automated testing was sufficient. It isn't, but it certainly goes a long way towards helping make the manual tester's lives better, by letting them focus on finding those problems that aren't (for one reason or another) reproducible in an automated testing scenario. Later, Chris
Re: [gentoo-dev] RFC: Making largefile a global use
On 03/10/2011 02:35 AM, Mike Frysinger wrote: i cant see much value anymore in even making this an option. just drop the USE flag and always use LFS. -mike +1
Re: [gentoo-dev] Quantity of open bugs
On 03/10/2011 02:25 PM, Kevin F. Quinn wrote: Hi all, I was nosing through bugzilla, and noticed: * Number of open bugs is greater than 14,000 * Number of open bugs untouched for more than 2 years - well over 2000. * Number of open bugs untouched between 1 and 2 years - well over 2000. * Number of open bugs untouched between 6 months and 1 year - well over 2000. * Number of open bugs untouched between 3 months and 6 months - over 2000 The winner is bug #78406, which hasn't been touched for over 2240 days - over 6 years - at the time of writing. I would guess these old untouched bugs aren't actually going to be touched, ever - a lot simply won't be relevant any more for one reason or another. All they're doing is cluttering up bugzilla. I think Duncan has already covered the major points I was going to mention: particularly with respect to the fact that we are all volunteers and thus subject to resource constraints that other projects might not have. I realize that it is frustrating to a user to have a bug sit for a year (or more) without ever being resolved (or even looked at), but there is really only one way to resolve that: get someone who has the time and expertise to step in and fill the gap. Given that we can't exactly hold a gun to people's heads and MAKE them work on Gentoo stuff (nor would I personally be inclined to trust code produced using such methods), I really don't see another alternative. We closed a number of bugs related to SELinux recently; many of those bugs had been open for quite some time and things had changed sufficiently that we believed that the bug itself was no longer relevant, or we needed feedback from the user and didn't get any. Some of those bugs had been open for a couple of years. But we reviewed EACH of those bugs and made a decision on a case-by-case basis. I understand and appreciate the desire to close open bugs that are cluttering up the bugzilla. Not only do they create extra cruft for everyone to wade through, they also make Gentoo look bad (my GOD, they've got open bugs dating back to the founding of the Roman Empire!). However, I'm not convinced that blanket closing bugs that are over x days (weeks, months, years) is the best (or even desirable) approach. If a bug is related to a package that no longer exists, then it seems pretty obvious that there is no need to keep the bug around. If the bug is waiting on feedback from a user, and that user hasn't provided the requested feedback in, say, 60 days (after a bump to the bug) then I'd say that the bug is arguably no longer of importance to the user, or at least the email address we have on file for that user doesn't work any more. Beyond those two conditions, I'd really be loathe to close anything without good evidence to indicate that it either is no longer relevant, or it can't be fixed. Just my $0.02 (not adjusted for currency devaluation) Later, Gizmo
Re: [gentoo-dev] Re: Lastrite: lince and slmodem
On 02/04/2011 05:24 PM, Diego Elio Pettenò wrote: This said, I'd suggest users and developers alike to add themselves (or ask to be added) to the metadata.xml files for packages requiring specific hardware support, so that even if one maintainer ends up not being active, we have a list of people who can actually tell us whether a given package works or not. And don't simply avoid doing so because there is someone else on that list already; we don't have a limit of one, two or three people listed in metadata.xml. The more people we know are ready to test a given package on actual hardware, the better (and you can be listed as just a tester after all). What's true of developers is also true of users; a user may add themselves to the list, forget they are on it, and a year from now be asked to test something they no longer have hardware for. Not saying that this isn't worth doing, merely pointing out that we may discover that we don't have anyone to test even WITH the list of willing users. Later, Chris
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/2010 03:38 PM, Rich Freeman wrote: On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysingervap...@gentoo.org wrote: personally, i dont see a problem here. what actual burden is there for continuing supporting EAPI 0/1 ? i dont think we should go around deprecating things for the pure fun of it. -mike I tend to agree, unless of course the maintainers of the various package managers chime in and say that some aspect of some particular EAPI requires them to maintain a lot of legacy code. Then I'd be all for dropping some. I'm not a gentoo dev, but I tend to agree here. If it ain't broke, don't fix it. Later, Gizmo
