On Tue, Jan 18, 2000 at 12:37:17AM -0600, Frederick Bruckman wrote:
> On Mon, 17 Jan 2000, Brian C. Grayson wrote:
> > 
> >   It won't be in 1.4.2.  1.4.2 should only be bug fixes to 1.4.1,
> > which was bug fixes to 1.4.  This is a new feature, so 1.5 is the
> > first full release that will have it.
> 
> I though the criteria for pull-up was "bug fixes _and_ new features",
> the idea being not to break any existing functionality. If
> "mount_portal" wasn't useful in 1-4, you should request a pull-up, as
> you can't break what's already broken. A direct analogy would be the
> coda file-system, which required new syscalls for several ports. Now,
> if it turns out that mount_portal compiles cleanly against 1.4.1, no
> kernel hooks required, it's an even better candidate than coda.

  Okay, looks like my impression of the meaning of 1.4.X was
overly-conservative.  mount_portal was _useful_ back in 1.4 and
before -- it already had the tcp and fs capabilities.  The
new rfilter and wfilter capabilities are just _more_ useful.  :)

  If someone could verify that it compiles cleanly and works on
1.4.1, please let me know.  For that matter, if anyone is still
running 1.3, 1.2, 1.1, or 1.0, and would like to try it out, let
me know!  The soonest I could do any of this testing is _maybe_
this weekend, and probably not even then.

  My only other concern about requesting a pull-up is that not
too many people have really banged on the code to make sure
there are no bugs or security holes.  If I want to be devious,
I guess I could say I'm not going to request a pull-up until I
get several novel *filter entries (and running commentary, like
I've already done) from others, for inclusion into the examples
in /usr/share/examples/mount_portal.  :)

  Seriously, if you like it, play with it, and give me feedback.
Lots of people have said "Cool feature" but only one person has
said "Cool feature.  I used it to ...".  It turns out he also
uncovered a security bug.  That tells me it isn't suitable for
1.4.2 (yet).  :(

  Brian Grayson