Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Oct 2000 01:35:21 -0500
From:      "Jeffrey J. Mountin" <jeff-ml@mountin.net>
To:        "Daniel C. Sobral" <dcs@newsguy.com>, Kris Kennaway <kris@FreeBSD.ORG>
Cc:        Warner Losh <imp@village.org>, Paul Richards <paul@originative.co.uk>, cvs-committers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
Subject:   Re: cvs commit: src/usr.bin/finger finger.c
Message-ID:  <4.3.2.20001004010120.00b1cb50@207.227.119.2>
In-Reply-To: <39DAC368.C6C213B7@newsguy.com>
References:  <39DA182C.C70ED553@originative.co.uk> <39D98B55.126DAFC4@originative.co.uk> <200010022227.PAA62603@freefall.freebsd.org> <39D92E08.E00CF2E4@owp.csus.edu> <20001002180303.A40584@freefall.freebsd.org> <39D98B55.126DAFC4@originative.co.uk> <200010031530.JAA26493@harmony.village.org> <20001003124008.A4892@netmonger.net> <39DA182C.C70ED553@originative.co.uk> <200010031800.MAA27859@harmony.village.org> <20001003162720.D51546@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 02:43 PM 10/4/00 +0900, Daniel C. Sobral wrote:
>Kris Kennaway wrote:
> >
> > I think a formal MFC process may be too stifling, unless we have a
> > VERY responsive MFC team. Consider that we don't want the same thing
> > to happen as did with 3.x, where 4.0-CURRENT was allowed to diverge so
> > much that merging bugfixes became difficult.
>
>I don't think the comparision is appropriate. The divergence between 3.x
>and 4.x came at the very beginning of 3.x's life, and it was not merged
>back because it was too big a change.

Aren't the SMP changes in -current similar and will reduce the amount of 
code that can be backported to -stable with relative ease.

"Allowed to diverge" smacks of halting progress and some changes are 
painful.  I'm not one to get into detail or give examples, which would be 
better suited on -arch and -hackers, but will say that divergence in 
userland is more likely to slow/stunt/make a PITA out of MFC'ing than 
kernel changes.  Don't think the pain of change can be avoided, but in 
general some do put more thought into changes than others and take the time 
to consider if -stable can benefit.  Simply are the gains worth the cost.

Can't really come up with a blanket to wrap the ideas here simply.  Can say 
that after the SMP changes in -current the ratio of -current to -stable 
commits dropped.  In and of itself that doesn't say much.  There are quite 
a few commits to -stable (even since 4.1.1) and even 3.x and lest we forget 
that -current is the development branch.

Some things just have to wait.  I recall waiting for 3.x and SMP, many 
improvements again in 4.x, and am waiting once more (not sure for what just 
yet, but I'm waaay behind with my -current mail.  Hardly expect more then 
some of the bigger changes (if any) will make it back from -current to 
-stable.  Almost seems like to solve the divergence issue we must merge 
-current and -stable, making the latter a well tested snapshot of the 
former.  Not one of them, but there were cases for a production environment 
where -current was needed.  Prior to 4.0R NFS was probably the best example.

It is also quite possible that the divergence and Jordan's observation that 
it's hard to get -current developers to MFC, that with the fewer changes 
filtering back that more time was spent working on the "new and improved" 
to make 4.0 such an excellent release.

Just may not be possible to have our cake and eat it too.


Personally I think endless discussions that go nowhere have been hurting 
the amount of comitting.  Recently the amount of commits seems to have 
slowed quite a bit.  This may be a good thing if the developers are wading 
through their mail.  Perhaps those of us that don't code should be a bit 
more quiet.  This thread is an exception, but -security has gone to pot and 
yes this is CC'd to -security, but no longer belongs there.  Nor does it's 
spin-off, which I plan to wade through in the hope of a glimmer. <sigh>


Jeff Mountin - jeff@mountin.net
Systems/Network Administrator
FreeBSD - the power to serve



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




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