Re: buffer cache & ufs changes (preliminary ffsv2 extattr support)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jan 16, 2012 at 08:38:28PM -0500, Mouse wrote:
 > >> And I think the master tree for a (supposedly-)production OS is not
 > >> the place to be carrying out research experiments, not even if
 > >> another such OS is already doing it.
 > 
 > > The trouble, of course, is that there isn't really any such thing
 > > these days as a research platform OS useful for such experiments.
 > 
 > I think NetBSD actually would be a fine platform for it.

Well, sort of. For architectural experiments (as opposed to localized
tweaks to filesystems or network protocols or whatever) you really
want a small and flexible platform. Whether you get it by cutting down
a production system or building a new system (or some mixture) the
trick is figuring out what legacy stuff you need for a convincing
proof of concept, and what's deadweight. NetBSD includes a lot of
stuff that's deadweight for such purposes (beginning with but not
limited to all the historical compat code) so as it stands it's quite
a bit less than ideal.

 > Just not in the main tree.

Yes.

 > I'd suggest just having two long-running branches, an experimental
 > system and a production system, with things pulled back and forth as
 > appropriate, but I think that probably needs a switch away from CVS as
 > a prerequisite, and we all know where _that_ can of worms leads.  I've
 > got a pile of things that could go into the experimental tree myself.
 > (They're mostly in production use on my personal machines, but that
 > hardly qualifies as anything more than successful alpha test.)
 > 
 > Also, maintaining NetBSD-experimental and NetBSD-production doubles
 > certain overhead loads and increases (but not to 2x) others, thus
 > further (putatively) draining already-scarce resources....

I was actually thinking about setting something like this up a while
back, but there's a fairly large problem: if the experimental branch
doesn't get much use it'll always be behind and always needing
merging, and thus not very useful, which is a self-perpetuating state
that defeats the purpose; however, if it does, there's a danger that
it effectively becomes HEAD, with the production branch functioning at
best like a stable branch, and that leaves us more or less where we
already are except with a much worse prognosis for whether -current
works on any given day.

The conclusion I came to is that it isn't really a good idea.

I think it might work to maintain a cut-down branch that can be used
as a *base* for experiments but that does not itself actually contain
any experiments (which would have to be proven on their own and then
merged directly into the trunk) but it's not clear if this is worth
the trouble vs. just experimenting on a private copy of HEAD.

Anyway as you note it's not likely workable if it involves CVS
branches.

-- 
David A. Holland
dholland%netbsd.org@localhost