Ports system quality

[Chad Perrin]

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 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20110829/9ba5c2a7/attachment.pgp