Freezing.. (was Re: Intel P6 vs P7 system call performance)

Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Linus Torvalds]

On Wed, 18 Dec 2002, Dave Jones wrote:
> On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
>  > [Extremely interesting new syscall mechanism tread elided]
>  >
>  > What happened to "feature freeze"?
>
> *bites lip* it's fairly low impact *duck*.

However, it's a fair question.

I've been wondering how to formalize patch acceptance at code freeze, but
it might be a good idea to start talking about some way to maybe put
brakes on patches earlier, ie some kind of "required approval process".

I think the system call thing is very localized and thus not a big issue,
but in general we do need to have something in place.

I just don't know what that "something" should be. Any ideas? I thought
about the code freeze require buy-in from three of four people (me, Alan,
Dave and Andrew come to mind) for a patch to go in, but that's probably
too draconian for now. Or is it (maybe start with "needs approval by two"
and switch it to three when going into code freeze)?

			Linus

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".

We went through this here for the bk-3.0 release.  We're a much smaller 
team so this may not work at all for you, but it was very successful 
for us, so much so that we are looking at formalizing it in BK.  But
you can apply the same process outside of BK just fine.

We created a well known spot for pending patches; all reviewers need access
to that spot.  Here's the README from that directory:

    There should be the following subdirectories here

	    ready/		-> waiting on review 
	    done/		-> in the tree
	    rejected/	-> no good


    In the ready/ subdirectory, for each repository which has changes that
    want to be in bk-3.0 but are not, I want:

	    ready/atrev -> /home/bk/wscott/bk-3.0-atrev
	    ready/atrev.RTI
	    ready/atrev.REVIEWED

    The first is a symlink to the location of the repository.

    The second is an RTI request which describes what is in the repo and why
    it should go in.

    The third contains the review comments in the form

	    lm (approved|not approved)
		    review comments
	    wscott (approved|not approved)
		    review comments
	    etc.

    Once the REVIEWED file contains enough approvals, in the judgement
    of the gatekeeper, then he pulls the repo into the bk-3.0 tree and moves
    the 3 files from ready/* to done/*

The things which worked very well were:

    a) extremely simple.  As we added developers they understood right away
       what the process was.
    b) centralized location.  Anyone could be bored and go do a review.
    c) tight control on the tree.



We're thinking about formalizing this in the context of BK as follows:

NAME
	bk queue - manage the queue of pending changes

DESCRIPTION
	bk queue is used to manage a queue of changes to a repository.
	It is typically used on integration repositories where tighter
	controls on change are desirable.  

	In all commands, if no URL is specified, the implied URL is the
	parent of the current repository, if any.  The URL "." means this
	repository.

	XXX - need a large paragraph on the importance of not circulating
	changesets which are in review state.  They'll come back.

	bk queue [-n<name>] [-R<rti>] [<URL>]
	    This is like a bk push but wants a "request to integrate"
	    (RTI) which is sent with the changes.  It also wants a name
	    for the set of changes.  All pending changesets are pushed.
	    If no name is given, the user is prompted for one.	If no
	    RTI is given, the user is prompted for one.

	bk queue -l [-n<name>] [<URL>]
	    Lists the set of pending changes in the queue like so:
	    <name> <date> <user> <state>

	    Values for the <state> field:
		unreviewed - nobody has looked at it yet
		reviewed by <reviewer> on <date> - obvious
		accepted - it is in accepted state but not integrated
		rejected - reviewed and rejected

	    Note that if there are multiple reviewers of a change, there
	    will be multiple lines in the listing for that change.

	    If the <name> arg is present then restrict the listing to 
	    that name.  If the <name> arg is present more than once,
	    restrict the listing to the set of named changes.

	    Could also have a -s<state> option which restricts the listing
	    to those changes in <state> state.

	bk queue -pR [-o<file>] <name> [<URL>]
	    Retrieves and displays the RTI for change <name>.  
	    If <file> is specified, put the form there.

	bk queue -pr [-o<file>] [-u<user>] <name> [<URL>]
	    Retrieves and displays the review form[s] for change <name>.
	    If a user is specified, retrieve that users' review only.
	    If <file> is specified, put the form there.

	bk queue -uR [<rti>] [<URL>]
	    Replaces any existing RTI with the specified RTI.  If no RTI
	    is specified, it prompts you for one like bk setup does.

	bk queue -ur [<review>] [<URL>]
	    Adds or replaces any existing review form with the specified
	    review.  If no review is specified, it prompts you for one
	    like bk setup does.  You may only replace your own reviews.  

	bk queue -O[<owner>] [<URL>]
	    Sets the owner of the repository to <owner>.  Only the owner
	    may update the repository.  Only the current owner can change
	    the ownership.  If no owner is specified and there is an owner
	    and the caller is the owner, then delete the owner.
	    (This is nothing more than a pre-{incoming,commit}-owner trigger)

	bk queue -d<name> [-f] [<URL>]
	    Delete the named change from the queue.  This deletes EVERYTHING,
	    the patch, rti, reviews, everything.  Only the submitter of the
	    change may delete the change unless the -f option is supplied.

	bk queue -U<name> [-R<rti>] [<URL>]
	    Replace the changes in the queue <name> with the set of
	    changesets in the current repository.  If the <rti> is
	    present, replace the current RTI form with the specified form.
	    All reviews, if any, are updated with a note that indicates
	    the existing review was against changes which have been replaced.

GUI
	This is a command line tool; Bryan gets to do bk queuetool
	using these interfaces.

TODO
	- how do we merge?  
	- define a format for the RTI
	- define a format for reviews
	- should the RTI & review files be KV files?
	- should the {name/RTI/REVIEWS} live as part of the repo and be
	  propogated?  I think yes for upstream propogation, no for 
	  downstream.  Hard to say.
	- need a way to add a queue item with no changes, i.e., an RFE which
	  needs to be in the tree but there are no changes yet.

FILES
	BitKeeper/queue/<name>/CSETS - changeset keys for change <name>
	BitKeeper/queue/<name>/RTI - RTI for change <name>
	BitKeeper/queue/<name>/PATCH - BK patch for change <name>
	BitKeeper/queue/<name>/RESYNC - exploded patch for change <name>
	BitKeeper/queue/<name>/review.user - review by user for change <name>
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Dave Jones]

On Wed, Dec 18, 2002 at 08:49:37AM -0800, Linus Torvalds wrote:

 > >  > What happened to "feature freeze"?
 > > *bites lip* it's fairly low impact *duck*.
 > However, it's a fair question.

Indeed. Were you merging something like preempt at this stage, I'd be wondering
if you'd broken out the eggnog a little too soon.

 > I just don't know what that "something" should be. Any ideas? I thought
 > about the code freeze require buy-in from three of four people (me, Alan,
 > Dave and Andrew come to mind) for a patch to go in, but that's probably
 > too draconian for now. Or is it (maybe start with "needs approval by two"
 > and switch it to three when going into code freeze)?

You'd likely need an odd number of folks in this cabal^Winner circle
though, or would you just do it and be damned if you got an equal
number of 'aye's and 'nay's ? 8-)

Other than that, it reminds me of the way the gcc folks work, with a
number of people reviewing patches before acceptance [not that this
doesn't happen on l-k already], and at least 1 approval from someone
prepared to approve submissions.

The approval process does seem to be quite a lot of work though.
I think it was rth last year at OLS who told me that at that time
he'd been doing more approving of other peoples stuff than coding himself.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Eli Carter]

Linus Torvalds wrote:
> 
> On Wed, 18 Dec 2002, Dave Jones wrote:
> 
>>On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
>> > [Extremely interesting new syscall mechanism tread elided]
>> >
>> > What happened to "feature freeze"?
>>
>>*bites lip* it's fairly low impact *duck*.
> 
> 
> However, it's a fair question.
> 
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
> 
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
> 
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?

Well, Linus, you're not the most conservative when it comes to freezes. 
   (Hey! Watch it with those thunderbolts!)  Alan, on the other hand, I 
would trust to be pretty conservative.
I'm afraid I haven't followed Dave & Andrew well enough in that light.

But my question is... if 2 are required, and say, Dave is as slushy on 
freezes as you are, then have we gained much?

Perhaps 2 of 4 approve with no dissenting votes?

If Dave and Andrew are relatively conservative on freezes, then this 
concern is sufficiently addressed already.

Food for thought from a relative nobody. ;)

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Andrew Morton]

Linus Torvalds wrote:
> 
> On Wed, 18 Dec 2002, Dave Jones wrote:
> > On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> >  > [Extremely interesting new syscall mechanism tread elided]
> >  >
> >  > What happened to "feature freeze"?
> >
> > *bites lip* it's fairly low impact *duck*.
> 
> However, it's a fair question.
> 
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
> 
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
> 
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
> 

It does sound a little bureacratic for this point in development.

The first thing we need is a set of widely-understood guidelines.
Such as:

Only
	- bugfixes
	- speedups
	- previously-agreed-to or in-progress features
	- totally new things (new drivers, new filesystems)

Once everyone understands this framework then it becomes easy to
decide what to drop, what not.

So right now, sysenter is "in".  Later, even "speedups" falls off
the list and sysenter would at that stage be "out".

Can it be that simple?

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Linus Torvalds]

On Wed, 18 Dec 2002, Dave Jones wrote:
>
>  > I just don't know what that "something" should be. Any ideas? I thought
>  > about the code freeze require buy-in from three of four people (me, Alan,
>  > Dave and Andrew come to mind) for a patch to go in, but that's probably
>  > too draconian for now. Or is it (maybe start with "needs approval by two"
>  > and switch it to three when going into code freeze)?
>
> You'd likely need an odd number of folks in this cabal^Winner circle
> though, or would you just do it and be damned if you got an equal
> number of 'aye's and 'nay's ? 8-)

Quite frankly, I wouldn't expect a lot of dissent.

I suspect a group approach has very little inherent disagreement, and to
me the main result of having an "approval process" is to really just slow
things down and make people think about the submitting.  The actual
approval itself is secondary (it _looks_ like a primary objective, but in
real life it's just the _existence_ of rules that make more of a
difference).

> The approval process does seem to be quite a lot of work though.
> I think it was rth last year at OLS who told me that at that time
> he'd been doing more approving of other peoples stuff than coding himself.

I heartily disagree with the approval process for development, just
because it gets so much in the way and just annoys people. But for
stabilization, that's exactly what you want. So I think gcc is using the
approval process much too much, but apparently it works for them.

And I think it could work for the kernel too, especially the stable
releases and for the process of getting there. I just don't really know
how to set it up well.

		Linus

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Jeff Garzik]

Linus Torvalds wrote:
> On Wed, 18 Dec 2002, Dave Jones wrote:
>>The approval process does seem to be quite a lot of work though.
>>I think it was rth last year at OLS who told me that at that time
>>he'd been doing more approving of other peoples stuff than coding himself.
> 
> 
> I heartily disagree with the approval process for development, just
> because it gets so much in the way and just annoys people. But for
> stabilization, that's exactly what you want. So I think gcc is using the
> approval process much too much, but apparently it works for them.


gcc's approval process looks a lot like the Linux approval process. 
Dave's description of rth's work sounds a lot like the Linus Role in 
Linux...  with the exception I guess that there are multiple peer Linii 
in gcc, and they read every patch <runs for cover>  More seriously, gcc 
appears to be "post the patch to gcc-patches, hope someone applies it" 
which is a lot more like Linux than some think :)

	Jeff

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Mike Dresser]

On Wed, 18 Dec 2002, Jeff Garzik wrote:

> Linux...  with the exception I guess that there are multiple peer Linii

Perhaps this is the solution.  Would someone please obtain a DNA sample
from Linus?

Mike

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[John Alvord]

On Wed, 18 Dec 2002 08:49:37 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> wrote:

>
>
>On Wed, 18 Dec 2002, Dave Jones wrote:
>> On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
>>  > [Extremely interesting new syscall mechanism tread elided]
>>  >
>>  > What happened to "feature freeze"?
>>
>> *bites lip* it's fairly low impact *duck*.
>
>However, it's a fair question.
>
>I've been wondering how to formalize patch acceptance at code freeze, but
>it might be a good idea to start talking about some way to maybe put
>brakes on patches earlier, ie some kind of "required approval process".
>
>I think the system call thing is very localized and thus not a big issue,
>but in general we do need to have something in place.
>
>I just don't know what that "something" should be. Any ideas? I thought
>about the code freeze require buy-in from three of four people (me, Alan,
>Dave and Andrew come to mind) for a patch to go in, but that's probably
>too draconian for now. Or is it (maybe start with "needs approval by two"
>and switch it to three when going into code freeze)?
>
>			Linus

I think there should be a distinction between changes which make an
API change/new function/user interface change, versus bug fixes,
adapting to new APIs, documentation, etc.

john alvord

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

> And I think it could work for the kernel too, especially the stable
> releases and for the process of getting there. I just don't really know
> how to set it up well.

A start might be

1.	Ack large patches you don't want with "Not for 2.6" instead
	of ignoring them. I'm bored of seeing the 18th resend of 
	this and that wildly bogus patch. 

	Then people know the status

2.	Apply patches only after they have been approved by the maintainer
	of that code area.

	Where it is core code run it past Andrew, Al and other people
	with extremely good taste.

3.	Anything which changes core stuff and needs new tools, setup
	etc please just say NO to for now. Modules was a mistake (hindsight
	I grant is a great thing), but its done. We don't want any more


4.	Violate 1-3 when appropriate as always, but preferably not to
	often and after consulting the good taste department 8)

Alan

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

Make it async.  So anyone can review stuff and record their feelings in a
centralized place.  We have a spare machine set up, kernel.bkbits.net, 
that could be used as a dumping grounds for patches and reviews if
master.kernel.org is too locked down.

If you force the review process into a "push" model where patches are 
sent to someone, then you are stuck waiting for them to review it and
it may or may not happen.  Do the reviews in a centralized place where
everyone can see them and add their own comments.

On Wed, Dec 18, 2002 at 02:08:02PM -0500, Alan Cox wrote:
> > And I think it could work for the kernel too, especially the stable
> > releases and for the process of getting there. I just don't really know
> > how to set it up well.
> 
> A start might be
> 
> 1.	Ack large patches you don't want with "Not for 2.6" instead
> 	of ignoring them. I'm bored of seeing the 18th resend of 
> 	this and that wildly bogus patch. 
> 
> 	Then people know the status
> 
> 2.	Apply patches only after they have been approved by the maintainer
> 	of that code area.
> 
> 	Where it is core code run it past Andrew, Al and other people
> 	with extremely good taste.
> 
> 3.	Anything which changes core stuff and needs new tools, setup
> 	etc please just say NO to for now. Modules was a mistake (hindsight
> 	I grant is a great thing), but its done. We don't want any more
> 
> 
> 4.	Violate 1-3 when appropriate as always, but preferably not to
> 	often and after consulting the good taste department 8)
> 
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

We've got one - its called linux-kernel.

Alan

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> We've got one - its called linux-kernel.

Huh?  That's like saying "we don't need a bug database, we have a mailing
list".  That's patently wrong and so is your statement.  If you want 
reviews you need some place to store them.  A mailing list isn't storage.

You'll do it however you want of course, but you are being stupid about it.
Why is that?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

> On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > We've got one - its called linux-kernel.
> 
> Huh?  That's like saying "we don't need a bug database, we have a mailing
> list".  That's patently wrong and so is your statement.  If you want 
> reviews you need some place to store them.  A mailing list isn't storage.
> 
> You'll do it however you want of course, but you are being stupid about it.
> Why is that?

We've got a bug database (bugzilla), we've got a system for seeing what opinion
appears to be -kernel-list

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

On Wed, Dec 18, 2002 at 02:42:51PM -0500, Alan Cox wrote:
> > On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > > We've got one - its called linux-kernel.
> > 
> > Huh?  That's like saying "we don't need a bug database, we have a mailing
> > list".  That's patently wrong and so is your statement.  If you want 
> > reviews you need some place to store them.  A mailing list isn't storage.
> > 
> > You'll do it however you want of course, but you are being stupid about it.
> > Why is that?
> 
> We've got a bug database (bugzilla), we've got a system for seeing what opinion
> appears to be -kernel-list

And exactly how is your statement different than

    "we have a system for seeing what bugs appear to be -kernel-list"

?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Oliver Xymoron]

On Wed, Dec 18, 2002 at 09:41:15AM -0800, Linus Torvalds wrote:
> 
> > The approval process does seem to be quite a lot of work though.
> > I think it was rth last year at OLS who told me that at that time
> > he'd been doing more approving of other peoples stuff than coding himself.
> 
> I heartily disagree with the approval process for development, just
> because it gets so much in the way and just annoys people. But for
> stabilization, that's exactly what you want. So I think gcc is using the
> approval process much too much, but apparently it works for them.
> 
> And I think it could work for the kernel too, especially the stable
> releases and for the process of getting there. I just don't really know
> how to set it up well.

Actually, I think Marcello's got the stable process pretty well
figured out without any of this committee business. And given that his
credibility as 2.4 maintainer depends on his holding to the mandate to
make the kernel stable, he probably doesn't have too hard a time
holding the line. As benevolent dictator, you're simply not beholden
to such expectations and I doubt the committee approach would work for
long either.

So perhaps you should throw out a date for 'code freeze' and then plan to
hand off to the 2.6 maintainer at that date. 

The other piece that will help is if the timeline for 2.7 shows up
around then and is short enough so that people won't despair of ever
getting their big feature in.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[John Bradford]

> On Wed, Dec 18, 2002 at 02:42:51PM -0500, Alan Cox wrote:
> > > On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > > > We've got one - its called linux-kernel.
> > > 
> > > Huh?  That's like saying "we don't need a bug database, we have a mailing
> > > list".  That's patently wrong and so is your statement.  If you want 
> > > reviews you need some place to store them.  A mailing list isn't storage.
> > > 
> > > You'll do it however you want of course, but you are being
> > > stupid about it.
> > > Why is that?
> > 
> > We've got a bug database (bugzilla), we've got a system for seeing
> > what opinion appears to be -kernel-list
> 
> And exactly how is your statement different than
> 
>     "we have a system for seeing what bugs appear to be -kernel-list"
> 
> ?

This forthcoming BK-related flamewar falls in to category 1, I.E. is
not a 2.6 feature :-)

John.

RE: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Nakajima, Jun]

BTW, in terms of validation, I think we might want to compare the results from LTP (http://ltp.sourceforge.net/), for example, by having it run on the two setups (sysenter/sysexit and int/iret). 

Jun

> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> Sent: Wednesday, December 18, 2002 8:50 AM
> To: Dave Jones
> Cc: Horst von Brand; linux-kernel@vger.kernel.org; Alan Cox; Andrew Morton
> Subject: Freezing.. (was Re: Intel P6 vs P7 system call performance)
> 
> 
> 
> On Wed, 18 Dec 2002, Dave Jones wrote:
> > On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> >  > [Extremely interesting new syscall mechanism tread elided]
> >  >
> >  > What happened to "feature freeze"?
> >
> > *bites lip* it's fairly low impact *duck*.
> 
> However, it's a fair question.
> 
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
> 
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
> 
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
> 
> 			Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

> > And exactly how is your statement different than
> > 
> >     "we have a system for seeing what bugs appear to be -kernel-list"
> > ?
> 
> This forthcoming BK-related flamewar falls in to category 1, I.E. is
> not a 2.6 feature :-)

I don't understand why BK is part of the conversation.  It has nothing to
do with it.  If every time I post to this list the assumption is that it's
"time to beat larry up about BK" then it's time for me to get off the list.

I can understand it when we're discussing BK; other than that, it's pretty
friggin lame.  If that's what was behind your posts, Alan, there is an
easy procmail fix for that.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[John Bradford]

> > This forthcoming BK-related flamewar falls in to category 1, I.E. is
> > not a 2.6 feature :-)
> 
> I don't understand why BK is part of the conversation.  It has nothing to
> do with it.  If every time I post to this list the assumption is that it's
> "time to beat larry up about BK" then it's time for me to get off
> the list.
> I can understand it when we're discussing BK; other than that, it's pretty
> friggin lame.  If that's what was behind your posts, Alan, there is an
> easy procmail fix for that.

My interpretation was that that is what he meant.  If I was wrong, I
appologise.

I was trying to point out in an amusing way that a repeat of the BK
flamewar we've seen on LKML was inappropriate.

John.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

> I don't understand why BK is part of the conversation.  It has nothing to
> do with it.  If every time I post to this list the assumption is that it's
> "time to beat larry up about BK" then it's time for me to get off the list.
> 
> I can understand it when we're discussing BK; other than that, it's pretty
> friggin lame.  If that's what was behind your posts, Alan, there is an
> easy procmail fix for that.

It wasnt me who brought up bitkeeper

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

> > > I can understand it when we're discussing BK; other than that, it's pretty
> > > friggin lame.  If that's what was behind your posts, Alan, there is an
> > > easy procmail fix for that.
> > 
> > It wasnt me who brought up bitkeeper
> 
> PLONK.  Into kernel-spam you go.  I've had it with ax grinders.

Oh dear me. Larry McVoy has flipped

I'm now being added to his spam list for *not* mentioning bitkeeper

Poor Larry, I hope has a nice christmas break, he clearly needs it

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Russell King]

On Thu, Dec 19, 2002 at 01:09:17AM +0000, Alan Cox wrote:
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?

I'm waiting for the kernel bugzilla to become useful - currently the
record for me has been:

3 bugs total
3 bugs for serial code for drivers I don't maintain, reassigned to mbligh.

This means I write (choose one):

1. non-buggy code (highly unlikely)
2. code no one tests
3. code people do test but report via other means (eg, email, irc)

If it's (3), which it seems to be, it means that bugzilla is failing to
do its job properly, which is most unfortunate.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy]

On Wed, Dec 18, 2002 at 07:18:44PM -0500, Alan Cox wrote:
> > > > I can understand it when we're discussing BK; other than that, it's pretty
> > > > friggin lame.  If that's what was behind your posts, Alan, there is an
> > > > easy procmail fix for that.
> > > 
> > > It wasnt me who brought up bitkeeper
> > 
> > PLONK.  Into kernel-spam you go.  I've had it with ax grinders.
> 
> Oh dear me. Larry McVoy has flipped
> 
> I'm now being added to his spam list for *not* mentioning bitkeeper
> 
> Poor Larry, I hope has a nice christmas break, he clearly needs it

Look, Alan and anyone else, I'm sort of sick of the flames about BK.
It's apparent that there will always be people who are looking for
excuses to attack BK because it isn't GPLed and how dare the kernel
hackers use it.  Your mail was so senseless that that was the only sane
explanation I could find and apparently I wasn't being paranoid, that's
what John thought as well.

I have a bad habit of taking things personally and too seriously and
the result is that attacks on me/BK/whatever, imagined or real, stress
me out and waste my time.  Life's too short to for me to deal with that
nonsense anymore.  I discovered procmail and I dump people into a spam
file if I feel they have a track record of yanking my chain.  It's my
fault that I'm such a wuss that I can't handle it but this works.
It's not personal, it's about having a more pleasant life and I find
things to be more pleasant without the flames.

I'll still read your mail, I do so about every 2 weeks, but that way 
whatever yankage you were (or were not) trying to do is in the past and
I'll ignore it.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[John Bradford]

> > I don't understand why BK is part of the conversation.  It has nothing to
> > do with it.  If every time I post to this list the assumption is that it's
> > "time to beat larry up about BK" then it's time for me to get off the list.
> > 
> > I can understand it when we're discussing BK; other than that, it's pretty
> > friggin lame.  If that's what was behind your posts, Alan, there is an
> > easy procmail fix for that.
> 
> It wasnt me who brought up bitkeeper
> 

No, it's my fault - I was skimming through list traffic, and not
concentrating, (proof of this is the fact that I've had sendmail
configured incorrectly all day, and been posting from the wrong
address, and only just realised :-) ).

I saw Larry mention kernel.bkbits.net, and Alan say, "We've got one -
its called linux-kernel", (in a separate message without quoting
anything, so it's really your fault :-) :-) :-) ), and assumed that a
BK argument was imminent, and I made a joke comment that it, (an
argument), was not a 2.6 required feature.

Sorry about the wasted bandwidth, I'll stop posting as it's now past
midnight, and I obviously need sleep.

Oh, 2.4.20-pre2 compiled OK for me, I hope that proves I've done
something useful tonight.

John.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Jeff Garzik]

On Thu, Dec 19, 2002 at 12:37:40AM +0000, Russell King wrote:
> This means I write (choose one):
> 3. code people do test but report via other means (eg, email, irc)

> If it's (3), which it seems to be, it means that bugzilla is failing to
> do its job properly, which is most unfortunate.

Given that it started around Halloween, I would at least give it a
chance before claiming its failure.  :)

IMO Bugzilla is gonna become even more useful as the code freeze hits,
and there are bugs we want to track until we get around to fixing
them...

	Jeff

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[John Bradford]

> > I was trying to point out in an amusing way that a repeat of the BK
> > flamewar we've seen on LKML was inappropriate.
> 
> I got the joke but I don't have a US postal address 8)

Eh???  US postal address?  What!?  Now I am really confused.

> More seriously we have defect tracking now - > bugzilla.kernel.org
> We have an advanced scalable groupware communication environment (email)
> 
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?

I don't like bugzilla particularly, it's too clunky, and it's
difficult to check that you are not entering a duplicate bug when the
database gets too big.  Maybe that's just my opinion, though.  Maybe I
should write a better bug tracking system...

John.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Adam J. Richter]

Russell King wrote:
>I'm waiting for the kernel bugzilla to become useful - currently the
>record for me has been:
>
>3 bugs total
>3 bugs for serial code for drivers I don't maintain, reassigned to mbligh.
>
>This means I write (choose one):
>
>1. non-buggy code (highly unlikely)
>2. code no one tests
>3. code people do test but report via other means (eg, email, irc)
>
>If it's (3), which it seems to be, it means that bugzilla is failing to
>do its job properly, which is most unfortunate.

	I don't currently use bugzilla (just due to inertia), but the
whole world doesn't have to switch to something overnight in order for
that facility to end up saving more time and resources than it has
cost.  Adoption can grow gradually, and it's probably easier to work
out bugs (in bugzilla) and improvements that way anyhow.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Alan Cox]

On Wed, 2002-12-18 at 22:37, John Bradford wrote: 
> I was trying to point out in an amusing way that a repeat of the BK
> flamewar we've seen on LKML was inappropriate.

I got the joke but I don't have a US postal address 8)

More seriously we have defect tracking now - > bugzilla.kernel.org
We have an advanced scalable groupware communication environment (email)

How the actual patches get applied really isnt relevant. I know Linus
hated jitterbug, Im guessing he hates bugzilla too ?

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Linus Torvalds]

On 19 Dec 2002, Alan Cox wrote:
> 
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?

I didn't start out hating jitterbug, I tried it for a while.

I ended up not really being able to work with anything that was so
email-hostile. You had to click on things from a browser, write passwords,
and generally just act "gooey", instead of getting things just _done_.

If I can't do my work by email from a standard keyboard interface, it's
just not worth it. Maybe bugzilla works better, but I seriously expect it
to help _others_ track bugs more than it helps me.

Which is fine. We don't all have to agree on the tools or on how to track 
stuff. The worst we can do (I think) is to _force_ people to work some 
way.

[ This is where the angel chorus behind me started singing "Why can't we 
  all live together in peace and harmony" and put up a big banner saying 
  "Larry [heart] Alan". At that point my fever-induced brain just said 
  "plop" ]

		Linus

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Martin J. Bligh]

> This means I write (choose one):
> 
> 1. non-buggy code (highly unlikely)
> 2. code no one tests
> 3. code people do test but report via other means (eg, email, irc)
> 
> If it's (3), which it seems to be, it means that bugzilla is failing to
> do its job properly, which is most unfortunate.

Not everyone will end up using it ... if people want to log bugs from
lkml into bugzilla, I think that'd help gather a critical mass.

Are you getting a lot of bug-reports for serial code on lkml? I use it
heavily, and it seems to work just fine to me .... so I pick (1). Yay! ;-)

Some of the bugs in there lie fallow, but I've seen quite a few get fixed.
The fact that some people (Dave Jones springs to mind) trawl through there
being extremely helpful fixing things is very useful ;-) Lots of things got
fixed, though I can't *prove* it was solely due to it being in Bugzilla.

As the list of bugs increases, it'll become an increasingly powerful 
search engine for information as well .... I'll draw up a list of things
that don't seem to being worked on, and mail it out to kernel-janitors
and/or lkml and see if people are interested in fixing some of the fallow
stuff.

M.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Timothy D. Witham]

Related thought:

  One of the things that we are trying to do is to automate 
patch testing.

  The PLM (www.osdl.org/plm) takes every patch that it gets
and does a quick "Does it compile test".  Right now there
are only 4 kernel configuration files that we try but we are
going to be adding more.  We could expand this to 100's 
if needed as it would just be a matter of adding additional
hardware to make the compiles go faster in parallel.

  Here is the example of the output from a baseline kernel.

http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=986

  A patch would look the same.  The PASS reports are really
short and the FAIL reports just give you the configuration 
files and the tail of the output from the kernel make.

 We've talked to a couple of system vendors about expanding
this to take the configurations that have passed and running
them on their 10's of hardware platforms of interest and we 
would be very happy to expand this to a very large number of
configurations of all sorts.

Tim

On Wed, 2002-12-18 at 11:08, Alan Cox wrote:
> > And I think it could work for the kernel too, especially the stable
> > releases and for the process of getting there. I just don't really know
> > how to set it up well.
> 
> A start might be
> 
> 1.	Ack large patches you don't want with "Not for 2.6" instead
> 	of ignoring them. I'm bored of seeing the 18th resend of 
> 	this and that wildly bogus patch. 
> 
> 	Then people know the status
> 
> 2.	Apply patches only after they have been approved by the maintainer
> 	of that code area.
> 
> 	Where it is core code run it past Andrew, Al and other people
> 	with extremely good taste.
> 
> 3.	Anything which changes core stuff and needs new tools, setup
> 	etc please just say NO to for now. Modules was a mistake (hindsight
> 	I grant is a great thing), but its done. We don't want any more
> 
> 
> 4.	Violate 1-3 when appropriate as always, but preferably not to
> 	often and after consulting the good taste department 8)
> 
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Timothy D. Witham <wookie@osdl.org>
Open Sourcre Development Lab, Inc

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Timothy D. Witham]

On Wed, 2002-12-18 at 22:43, Andrew Morton wrote:
> "Timothy D. Witham" wrote:
> > 
> > Related thought:
> > 
> >   One of the things that we are trying to do is to automate
> > patch testing.
> > 
> >   The PLM (www.osdl.org/plm) takes every patch that it gets
> > and does a quick "Does it compile test".  Right now there
> > are only 4 kernel configuration files that we try but we are
> > going to be adding more.  We could expand this to 100's
> > if needed as it would just be a matter of adding additional
> > hardware to make the compiles go faster in parallel.
> 
> It would be valuable to be able to test that things compile
> cleanly on non-ia32 machines.  And boot, too.
> 
  The way the software is configured it is fairly easy to
add multiple servers (even different instruction sets) that
have the complies farmed out to them.

> That's probably a lot of ongoing work though.

  The largest portion of the work would be keeping
up with the breakages in the trees.

BTW I'm in Japan so my access times are going to be
a little strange.
-- 
Timothy D. Witham - Lab Director - wookie@osdlab.org
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Timothy D. Witham]

  Sorry, they changed it last week and my fingers still
have the old firmware. 

  www.osdl.org/cgi-bin/plm

TIm

On Wed, 2002-12-18 at 23:05, Martin J. Bligh wrote:
> > Related thought:
> >
> >   One of the things that we are trying to do is to automate
> > patch testing.
> >
> >   The PLM (www.osdl.org/plm) takes every patch that it gets
> > and does a quick "Does it compile test".  Right now there
> > are only 4 kernel configuration files that we try but we are
> > going to be adding more.  We could expand this to 100's
> > if needed as it would just be a matter of adding additional
> > hardware to make the compiles go faster in parallel.
> 
> URL doesn't seem to work. But would be cool if you had one SMP
> config, one UP with IO/APIC, and one without IO/APIC. I seem
> to break the middle one whenever I write a patch ;-(
> 
> M.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Timothy D. Witham - Lab Director - wookie@osdlab.org
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Andrew Morton]

"Timothy D. Witham" wrote:
> 
> Related thought:
> 
>   One of the things that we are trying to do is to automate
> patch testing.
> 
>   The PLM (www.osdl.org/plm) takes every patch that it gets
> and does a quick "Does it compile test".  Right now there
> are only 4 kernel configuration files that we try but we are
> going to be adding more.  We could expand this to 100's
> if needed as it would just be a matter of adding additional
> hardware to make the compiles go faster in parallel.

It would be valuable to be able to test that things compile
cleanly on non-ia32 machines.  And boot, too.

That's probably a lot of ongoing work though.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Martin J. Bligh]

> Related thought:
>
>   One of the things that we are trying to do is to automate
> patch testing.
>
>   The PLM (www.osdl.org/plm) takes every patch that it gets
> and does a quick "Does it compile test".  Right now there
> are only 4 kernel configuration files that we try but we are
> going to be adding more.  We could expand this to 100's
> if needed as it would just be a matter of adding additional
> hardware to make the compiles go faster in parallel.

URL doesn't seem to work. But would be cool if you had one SMP
config, one UP with IO/APIC, and one without IO/APIC. I seem
to break the middle one whenever I write a patch ;-(

M.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Russell King]

On Wed, Dec 18, 2002 at 05:08:45PM -0800, Adam J. Richter wrote:
> 	I don't currently use bugzilla (just due to inertia), but the
> whole world doesn't have to switch to something overnight in order for
> that facility to end up saving more time and resources than it has
> cost.  Adoption can grow gradually, and it's probably easier to work
> out bugs (in bugzilla) and improvements that way anyhow.

I'm not asking the world to switch to it overnight.  Just one person
would be nice. 8)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Dave Jones]

On Thu, Dec 19, 2002 at 12:59:20AM +0000, John Bradford wrote:

 > I don't like bugzilla particularly, it's too clunky, and it's
 > difficult to check that you are not entering a duplicate bug when the
 > database gets too big.

File bug anyway and worry about it later. The bugzilla elves regularly
go through the database cleaning up crufty bits, marking dupes,
closing invalids, world peace etc etc. It seems to be holding
up well so far.  Of the 180 bugs filed, I think I've personally rejected
<10 dupes/invalids. Other folks haven't done that many too.
Here's to hoping it continues to remain high signal.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Dave Jones]

On Thu, Dec 19, 2002 at 12:37:40AM +0000, Russell King wrote:
 > On Thu, Dec 19, 2002 at 01:09:17AM +0000, Alan Cox wrote:
 > > How the actual patches get applied really isnt relevant. I know Linus
 > > hated jitterbug, Im guessing he hates bugzilla too ?
 > 
 > I'm waiting for the kernel bugzilla to become useful - currently the
 > record for me has been:
 > 
 > 3 bugs total
 > 3 bugs for serial code for drivers I don't maintain, reassigned to mbligh.

That was unfortunate, and you got dumped with those because some thought
"Ah, serial! RMK!".  Some of the categories in bugzilla still need
broadening IMO.

 > This means I write (choose one):
 > 1. non-buggy code (highly unlikely)
 > 2. code no one tests
 > 3. code people do test but report via other means (eg, email, irc)
 > 
 > If it's (3), which it seems to be, it means that bugzilla is failing to
 > do its job properly, which is most unfortunate.

It's early days. The types of bugs being filed still fall into the
"useful" "not useful" categories though.  I don't think it's really
that important that we track what doesn't compile at this stage.
Those reports are being either closed within a few hours of them
being opened with a "Fixed in BK", or are drivers which no-one currently
wants to fix/can fix (Things like the various sti/cli breakage)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Stephen Satchell]

At 02:08 PM 12/18/02 -0800, Larry McVoy wrote:
>I don't understand why BK is part of the conversation.  It has nothing to
>do with it.  If every time I post to this list the assumption is that it's
>"time to beat larry up about BK" then it's time for me to get off the list.
>
>I can understand it when we're discussing BK; other than that, it's pretty
>friggin lame.  If that's what was behind your posts, Alan, there is an
>easy procmail fix for that.

Boy, talk about humor-impaired.  When was the last time you got out and had 
some fun not related to computer, Larry?

I don't read more than 95 percent of this mailing list and I got the joke.

Lighten up, and take a hint from the nearest cat: see the toy in everything.

Satch, another relative nobody.


-- 
The human mind treats a new idea the way the body treats a strange
protein:  it rejects it.  -- P. Medawar
This posting is for entertainment purposes only; it is not a legal opinion.

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Eli Carter]

Russell King wrote:
> On Wed, Dec 18, 2002 at 05:08:45PM -0800, Adam J. Richter wrote:
> 
>>	I don't currently use bugzilla (just due to inertia), but the
>>whole world doesn't have to switch to something overnight in order for
>>that facility to end up saving more time and resources than it has
>>cost.  Adoption can grow gradually, and it's probably easier to work
>>out bugs (in bugzilla) and improvements that way anyhow.
> 
> 
> I'm not asking the world to switch to it overnight.  Just one person
> would be nice. 8)
> 

Ok, Russell, maybe I can lend a small hand there....

You have a bug tracking mechanism of your own on www.arm.linux.org.uk, 
along with a separate patch tracker.
Do you want ARM bug reports in bugzilla instead of your site?  If so, 
can you link to it from that bug tracker page?  (I suppose you'd want to 
  direct people to bugzilla for just 2.5.* and 2.5.*-rmk*)

I submitted a 2.4 bug to your bug tracker, got an answer to the question 
when I posted to the arm mailing lists (thanks!), and submitted a patch 
to the mailing list.  But nothing has happened on the bug status.  I 
asked if you wanted patches for bugs put in the patch tracker or the bug 
tracker, but got no reply.
I understand that you're fighting the Acorn battle of 2.5.50 -> 2.5.52, 
so I'm trying not to sound like I'm complaining.  (Failing, yes, I know, 
sorry. :/ )  Some assurance that you will acknowledge bugs in bugzilla 
would be greatly encouraging to me.  (Such as a reply to this message?)

I'll try to get 2.5 bug reports for ARM into bugzilla based on your 
comments here, but a couple of suggestions:
- post an announcement to the arm lists of where you want which bugs to go,
- link to the same in a prominent place from your bug and patch trackers
- if you can, perhaps give priority in terms of replies and such to 
those who use bugzilla... I value your replies, and if I can do 
something to increase my chances of even getting an "Ack, I'll look at 
it next week", I'll try to do that.

Comments?

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Kai Henningsen]

mdresser_l@windsormachine.com (Mike Dresser)  wrote on 18.12.02 in <Pine.LNX.4.33.0212181308380.11644-100000@router.windsormachine.com>:

> On Wed, 18 Dec 2002, Jeff Garzik wrote:
>
> > Linux...  with the exception I guess that there are multiple peer Linii
>
> Perhaps this is the solution.  Would someone please obtain a DNA sample
> from Linus?

It's been in the works for quite some time now, I gather, but the process  
is expected to take maybe two decades more before the first candidate  
becomes available.

It *was* announced here, however.

MfG Kai