tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



matthew green <mrg%eterna.com.au@localhost> wrote:
> 
> > David Holland <dholland-tech%netbsd.org@localhost> wrote:
> > > On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote:
> > >  > I consider lfs second-class citizen at this time and if forward
> > >  > compat if broken for the lfs module on the branch it's probably not
> > >  > a big deal).
> > > 
> > > I don't consider that acceptable...
> > > 
> > 
> > I am in agreement with Manuel.  Without going into argument on BSD LFS
> > design issues, current code is way too far from being anywhere stable
> > and reliable.  It should not block any progress in other subsystems.
> 
> irregardless of what LFS is or isn't, breaking it on the branch is
> not acceptable.  you might not use it or trust it, but there are
> people who do -- the people who maintain it -- and the same argument
> applies equally to their work as to any other work.

The point being is that such for a long time defective piece of code like
LFS should not block other features and general progress, nor it should
be preserved under any cost (like it was done in notorious SA case, when
today the code is still broken, unmaintained and hardly has any real
users).  There is also another point - user experience, which perhaps
deserves a wider discussion, but not on tech-kern.

> <..>
> more generally on this issue:
> 
> i don't think it matters if netbsd-6 and -current end up having
> non-trivially different implementations of this code.  what matters
> most is that we (a) release netbsd-6 soon and (b) keep it stable.
> 
> if non-trivial changes are necessary for ffsv2 extattr support to
> be part of netbsd-6 then i think that those changes have missed the
> boat.  if those changes can be kept localised, but not entirely
> clean, then netbsd-6 can still have the feature without the
> potential for disrupting the release.

It is a valid point, I agree.  On the other hand, Manuel's proposed
patch is not that invasive.  If there is a very clear benefit for having
it in, I do not see why with some management it could not be adopted
for netbsd-6.  Think of PostgreSQL's patch-fiesta model.

-- 
Mindaugas


Home | Main Index | Thread Index | Old Index