cvs commit: www/en/projects/ideas index.sgml

Alexander Leidinger Alexander at
Fri Jul 28 13:27:32 UTC 2006

Quoting Robert Watson <rwatson at> (from Fri, 28 Jul 2006  
13:45:50 +0100 (BST)):

> On Fri, 28 Jul 2006, Alexander Leidinger wrote:
>>> BTW, a problem that has occurred a number of times in the past is   
>>> that people have approached us with implementations of ideas in   
>>> the idea list that it has later transpired we aren't actually   
>>> interested in (sometimes at all).  I think it might not be a bad   
>>> idea to sprinkle the
>> My impression is, that we lack some committers which not only have   
>> time to review the submissions, but also have the necessary domain   
>> specific knowledge at the same time.
> I suggest marking unreviewed ideas as unreviewed then.  My biggest

Which isn't entirely true. We filter incoming ideas (we at least  
rejected one or two... after talking with the submitter), but we  
aren't able to distinguish good looking but bad ideas from good  
looking and good ideas. Some ideas are only rejectable by someone with  
enough domain specific knowledge and look ok for most other people.

So when do you think an entry is reviewed? How to determine whom to  
ask for review and how to get this person interested enough for a  

> concern is that we have people who come along, see the idea, implement
> it, and it's then dropped on the floor because it turns out we didn't
> really want it, but it was on the list.  If we don't want it, we
> shouldn't list it.  If we're not sure if we want it, but think it might
> be neat, then we should say that's why it's on the list, so as to avoid
> misunderstandings.

I agree.

>> We need some reviewers here... while I'm able to come up with a   
>> nice technical description of roughly expressed ideas (as long as I  
>>  get the idea), I'm not a TRB and as such aren't aware of every   
>> implication. And some ideas are expressed in a way which make them   
>> sound like it's "common knowledge to people which work in this   
>> field" (ATM I refer to the NFS lockd in kernel implementation idea).
> Given that we can't get the user space code to work and don't have an
> owner for it (it appears to be abandonware), I think moving it into the
> kernel would be a disaster.

Uhm... I'm withhin the implicit assumption that we first need to fix  
NFS lockd (an entry before the "move into the kernel" entry)... ok, we  
need to record dependencies here.

>> So: helping hands are welcome!
>> Thanks for taking some time to review some parts of the list.
> I'll try to take a look through the rest of them later today.


Let me put it this way: today is going to be a learning experience.    Alexander @ PGP ID = B0063FE7       netchild @  : PGP ID = 72077137

More information about the freebsd-hackers mailing list