Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jul 2006 15:27:28 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        hackers@FreeBSD.org, Joel Dahl <joel@FreeBSD.org>
Subject:   Re: cvs commit: www/en/projects/ideas index.sgml
Message-ID:  <20060728152728.3pwcc5glesc08c0k@netchild.homeip.net>
In-Reply-To: <20060728133744.D56782@fledge.watson.org>
References:  <200607280705.k6S7585g094248@repoman.freebsd.org> <20060728092503.U4612@fledge.watson.org> <20060728142237.lhocfctqugoocc48@netchild.homeip.net> <20060728133744.D56782@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@FreeBSD.org> (from Fri, 28 Jul 2006 =20
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  =20
>>> that people have approached us with implementations of ideas in  =20
>>> the idea list that it has later transpired we aren't actually  =20
>>> interested in (sometimes at all).  I think it might not be a bad  =20
>>> idea to sprinkle the
>>
>> My impression is, that we lack some committers which not only have  =20
>> time to review the submissions, but also have the necessary domain  =20
>> 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 =20
rejected one or two... after talking with the submitter), but we =20
aren't able to distinguish good looking but bad ideas from good =20
looking and good ideas. Some ideas are only rejectable by someone with =20
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 =20
ask for review and how to get this person interested enough for a =20
review?

> 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  =20
>> nice technical description of roughly expressed ideas (as long as I =20
>>  get the idea), I'm not a TRB and as such aren't aware of every  =20
>> implication. And some ideas are expressed in a way which make them  =20
>> sound like it's "common knowledge to people which work in this  =20
>> 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 =20
NFS lockd (an entry before the "move into the kernel" entry)... ok, we =20
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.

Thanks,
Alexander.

--=20
Let me put it this way: today is going to be a learning experience.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID =3D 72077137




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