In message [EMAIL PROTECTED], Matthew Dillon writes:
:I don't see anything justifying an immediate MFC in this patch. Please
:allow the normal waiting period to elapse before you MFC.
Unless you can justify a reason for it NOT to be MFC'd immediately, I
see no reason to wait for this
In message [EMAIL PROTECTED], Matthew Dillon writes:
There's another good reason to MFC the linux patch on wednesday...
that is, to do it at the same time the SMP cleanup is MFC'd, and that
is because both patch sets require the linux kernel module to be
recompiled and I'd
:In message [EMAIL PROTECTED], Matthew Dillon writes:
:
::I don't see anything justifying an immediate MFC in this patch. Please
::allow the normal waiting period to elapse before you MFC.
:
:Unless you can justify a reason for it NOT to be MFC'd immediately, I
:see no reason to wait for
In message [EMAIL PROTECTED], Matthew Dillon writes:
I'm sorry, Poul, but you are going to have to come up with better
reasoning then that.
Not all changes committed to -current require a waiting period before
being MFC'd to stable. Specifically, simple and obvious bug fixes
There's another good reason to MFC the linux patch on wednesday...
that is, to do it at the same time the SMP cleanup is MFC'd, and that
is because both patch sets require the linux kernel module to be
recompiled and I'd rather not force people to do that twice.
The SMP
This is the same patch I put up for review two weeks ago. I got one
positive comment back and nothing else, so I presume nobody has a
problem with it. I've been running with it for a while but have only
tested it with a few linux applications (Java (jre, jdk), and the oracle
In message [EMAIL PROTECTED], Matthew Dillon writes:
I intend to commit this to -current and immediately MFC it to -stable.
I don't expect there to be any controversy though I'm sure there is a
cleaner way to do it.
I don't see anything justifying an immediate MFC in this patch.
:
:In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:I intend to commit this to -current and immediately MFC it to -stable.
:I don't expect there to be any controversy though I'm sure there is a
:cleaner way to do it.
:
:I don't see anything justifying an immediate MFC in this
:
:In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:There's another good reason to MFC the linux patch on wednesday...
:that is, to do it at the same time the SMP cleanup is MFC'd, and that
:is because both patch sets require the linux kernel module to be
:recompiled and
There's another good reason to MFC the linux patch on wednesday...
that is, to do it at the same time the SMP cleanup is MFC'd, and that
is because both patch sets require the linux kernel module to be
recompiled and I'd rather not force people to do that twice.
The
Matt,
I will say it this last time:
Your patch does not qualify for immediate MFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
:
:In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:There's another good reason to MFC the linux patch on wednesday...
:that is, to do it at the same time the SMP cleanup is MFC'd, and that
:is because both patch sets require the linux kernel module to be
:
I do not consider the linux scripting patch to be a major infrastructure
change, I consider it to be a simple bug fix. If you have a functional
issue with the patch I'm all ears. If you disagree with my assessment of
the triviality of the linux scripting patch, then I will ask
I wonder if it makes sense to add a release id to the module header
and have the module loader refuse (unless forced) to load modules that
are out-of-date with the kernel?
We actually have a whole module dependancy and versioning system more or
less ready to go into -current. It
In message [EMAIL PROTECTED], Matthew Dillon writes:
Core should consider reverting the special rules that were originally
created with the expectation of major breakage in 5.x back to
the set of rules we had for 3.x and 4.x.
I have no idea what special rules you are talking about
:
:I do not consider the linux scripting patch to be a major infrastructure
:change, I consider it to be a simple bug fix. If you have a functional
:issue with the patch I'm all ears. If you disagree with my assessment of
:the triviality of the linux scripting patch, then I
:
:
:Matt,
:
:I will say it this last time:
:
: Your patch does not qualify for immediate MFC.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
And I will say this to you for the last time: Under the current rules
my patch DOES qualify for an immediate MFC. Hell, by
:
:In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:Core should consider reverting the special rules that were originally
:created with the expectation of major breakage in 5.x back to
:the set of rules we had for 3.x and 4.x.
:
:I have no idea what special rules you are
Nate Williams wrote:
I was under the impression that 4.x hasn't been designated as the stable
branch (yet). That will happen when 4.1 is released, but until that
happens 3.x is still considered the -stable release.
That would kinda make sense since cvsuping with tag=RELENG_3 seems to
give
Mike Muir wrote:
Nate Williams wrote:
I was under the impression that 4.x hasn't been designated as the stable
branch (yet). That will happen when 4.1 is released, but until that
happens 3.x is still considered the -stable release.
That would kinda make sense since cvsuping with
Core should consider reverting the special rules that were originally
created with the expectation of major breakage in 5.x back to
the set of rules we had for 3.x and 4.x.
I have no idea what special rules you are talking about for 4.x/5.x.
4.x-stable is a -stable tree and
On Sun, 23 Apr 2000, Matthew Dillon wrote:
If core wants to change the current rules, that's fine by me. As I
said before I think the breakage that we thought would happen with 5.x
due to the BSDI merger that prompted the loose rules for 4.x is
overrated, and the rules should
BTW; whilst I think Poul was entirely the wrong person to raise the
issue, I agree that you probably want to hang back on MFCing the linux
scripting changes for a week or so. This is really just common sense.
recently i added autoload to a usb related kernel module.
very handy
23 matches
Mail list logo
