On Mon, Aug 29, 2011 at 12:17:12AM -0700, Doug Barton wrote: > On 08/29/2011 00:07, Michal Varga wrote: > > On Sun, 2011-08-28 at 23:30 -0700, Doug Barton wrote: > >>> Testing only for "Does it still build?" won't help much anymore if > >>> the new version silently broke one of the APIs and while Apache > >>> still runs with it fine > >> > >> Believe it or not, I understand that. :) The problem is that > >> extensive run-time testing is not within the realm of possibility > >> without an army of volunteers. Do you want to organize that effort? > > > > That would be the very opposite of the concept I just described. > > While extensive volunteer testing, if considered standalone, is > > surely not a bad idea (just that for some reason it never happens > > anywhere), it lies in a completely different scope than port > > maintainers *not* randomly upgrading dependencies just on their own > > without regard to other ports they will affect (and in many cases > > break, be it on build level, or run-time level). > > Ok, I'll be more blunt. We don't do that on purpose, obviously. But > expecting maintainers to do what you're describing is unrealistic. The > only thing it would accomplish is a "stable" ports tree because nothing > would ever get updated. :) > > Seriously ... I get what you're saying, I'm not even saying it's a bad > idea, I'm just saying that we lack the person-power to do it now, and > are unlikely to ever get to that point. I would also point out that > from a project management standpoint developers rarely make good QA > people. To do this right you really would want separate teams.
Frankly, I think the one thing that would have the most dramatically and disproportionately positive effect on the quality and stability of ports would be an improvement in the toolsets available for porters -- not just the tools themselves, but the introduction to using them. Consider, for instance, the possibility of an automated system with minimal configuration and command syntax for pulling a port from a nonstandard source while still managing it using the standard ports system; it would make user testing much more palatable, even inviting, and thus make it easier for a port maintainer to encourage interested acquaintances to help test a port under varied conditions before it gets committed to the official ports tree. While I'm not a huge fan of the way the first chromium browser port's maintainer handled his "hybrid source" business model, I also think it would be nice to have a system for installation and management of nonstandard ports using the standard ports tools for purposes of offering a way for third-party software repositories to be offered for easy inclusion, too (let the buyer beware, of course). I'm pretty new to learning about how ports are maintained, so it's possible I've missed something -- but if I have, we're desperately lacking the sort of documentation that would make this stuff obvious and accessible to users and, perhaps, to port maintainers as well. I'd be happy to be shown where I am wrong about the lack of such facilities, of course. I'm sure that, if I am wrong about it, there are many other people out there who would be happy to discover that their inability to find reference to such facilities would be happy to be educated about the existence of such things, too. > >> > >> That sounds like PC-BSD to me. (Seriously, give it a try) > > > > Now that's like saying I might want to try *Linux and OS X too (I > > occasionally use both, just not as my primary desktop, which is > > FreeBSD). > > Those are good alternatives as well. I use FreeBSD as my desktop, but > it's painful, and I wouldn't do it at all if I didn't need to. > > FreeBSD needs to get better in this area, but I seriously doubt it will > ever be as easy and painless as something like ubuntu. For a great many use cases, Ubuntu is one of the most painful "desktop" user experiences I have ever encountered. Please, *please* do not emulate Ubuntu. Fundamental operations change with the blowing of the wind in Ubuntu for no good reason; its "don't make the user think" philosophy is taken to an absurd extreme that often results in it not only making decisions against the user's interests, but also *changing* a user's choices later on down the road; it installs software and runs servers the user will never have any occasion to use, with no obvious way to deactivate them; and it essentially enforces the use of huge collections of software by way of hopelessly intertangled dependencies. There's more, but I need to stop some time, because this is not a forum for Ubuntu-related discussion. The difficulties of using a "desktop" system built on the Ubuntu way of doing things is not "easy" and "painless" for a nontrivial selection of users, especially developers. I know people who work for Canonical on Ubuntu development who lament some of the difficulties of dealing with Ubuntu and, as my girlfriend once said (paraphrased), "If I wanted to deal with this crap I'd be using Windows." I use FreeBSD on my laptops because it is the *least* painful system to use for "desktop" purposes, in my experience. I like a system that offers the software and capaibilities I need without taking away from me the ability to actually control the system's configuration to a reasonable degree. Note that the laptop on which I'm typing this is an exception, because I bought it with an Intel Core i5 before I knew about the graphics support issues. That does not mean that the OS I'm running on it instead it is less painful to use for such a purpose than FreeBSD would be. I have only barely continued to lean to the side of not dealing with a 4:3 resolution stretched to a 16:9 display aspect ratio (as I would get with FreeBSD). The hassles and frustrations of a constantly changing Linux-based software ecosystem that seems intent on growing more non-deterministic in its behavior over time are very nearly enough to make me choose the horribly stretched resolution over these technical annoyances that do things like prevent me from connecting reliably to certain wireless networks. It has gotten bad enough that I have recently started using an older laptop for close to half of what I do, just so I can have a sane, stable environment (relative to MS Windows and any modern Linux distribution I've encountered). That is not to say that FreeBSD does not have its own annoyances (as this thread has pointed out, sometimes even accurately) -- but please do not go pursuing the policies of a system that throws away all the benefits that drew me to FreeBSD in the first place in search of a more "painless" user experience. I do not, at the moment, feel a burning need to find excuses to switch to NetBSD or OpenBSD as my primary laptop OS of choice. Don't let me throw fuel on the fire, here, but please don't throw out the baby with the bathwater, either. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
pgpJnVjxAaOsy.pgp
Description: PGP signature
