Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Apr 2011 00:57:44 -0500
From:      "Matthew D. Fuller" <fullermd@over-yonder.net>
To:        Eitan Adler <eadler@freebsd.org>
Cc:        FreeBSD Ports <ports@freebsd.org>
Subject:   Re: Removing Cruft from the ports tree
Message-ID:  <20110401055744.GY44849@over-yonder.net>
In-Reply-To: <AANLkTikmyPyY8q1xN47_dH3D6ndFoXYDaM3F%2BtWdFKe0@mail.gmail.com>
References:  <AANLkTikmyPyY8q1xN47_dH3D6ndFoXYDaM3F%2BtWdFKe0@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 31, 2011 at 11:55:02PM -0400 I heard the voice of
Eitan Adler, and lo! it spake thus:
> 
> Not only that but because maintainers would be able to choose the
> best possible configuration for the their port users would no longer
> have to mess around.

This doesn't sound like a good idea.  Options are important for the
capability they provide in routing around maintainer foibles, as well
as mere configurability in the abstract.  They provide an important
mechanism for crowdsourcing the optimal setup; sadly we've not managed
to properly collect and capitalize on the data, but that's no reason
to assume we can't in the future.

If we remove that workaround, I think we need to recognize that it's
just going to create a larger problem, and remove the stranglehold
maintainers have over what the user sees.  To be sure, nothing stops
other entities from distributing ports already, but with the current
setup the FreeBSD Project as a whole really applies a strong
imprimatur on the single maintainer-blessed setup, which is hard to
overcome even by the full community of users.


So, while removing OPTIONS alone may be good, we really need to
dismantle the system that caused the need for them in the first place
to avoid creating a greater mess.  I think it coud be useful to turn
to Wikipedia for an example (and indeed, not just an example, but a
pre-built distribution system!).  By simply eliminating any sort of
officially "blessed" ports tree (with all the complications and
liabilities that entails), encouraging users to set up Wikipedia pages
with recipes for building packages, and building a little
infrastructure (using sufficient tools already existing in the base
system; we can easily backport to 6.x and beyond) for fetching them
down and building on request, we can free up an enormous amount of
machine- and man-power, while making the result far more democratic.

Really, the only significant challenge is rogue vandalism, but again,
Wikipedia itself has already developed systems for handling that.  It
may take a little effort on our part to keep that up for our
particular needs, but surely far less than is currently required.  And
as an additional bonus, by having it available on an easily-editable
wiki, we can save all the trouble of submitting and load of dealing
with PR's, and reduce our dependance on gnats too.  It's pretty much
all upside, when you think about it.


-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110401055744.GY44849>