lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: access policy for Java Open Review Project
Date Wed, 27 Dec 2006 00:38:31 GMT
Brian,

Thanks for your continued efforts, and for this report about Lucli.

I'd be surprised if anyone uses Lucli, given the limited utility it  
has versus using Luke.

	Erik


On Dec 26, 2006, at 4:30 PM, Brian Chess wrote:

> Hi there, I didn't see any replies to my question about what to do  
> with
> outside auditors for the Java Open Revew Project. Our default  
> position is
> that we do not allow access to outsiders without permission from  
> the code
> maintainers, so unless I hear otherwise, we won't grant access to  
> outsiders
> for Lucene projects.  That's a fine policy as far as I'm  
> concerned.  I just
> wanted to let people know where we stand.
>
> Meanwhile, we're moving closer to performing regular analysis of  
> the code.
> On Friday we uploaded our second pass at Lucene.  I only took a  
> quick glance
> through the results, but this one caught my eye:
>
> Lucli.java line 286:
>     name.toLowerCase(); //treat uppercase and lower case commands  
> the same
>
> I'm pretty sure that line should be:
>     name = name.toLowerCase();
>
> I'll send another note when we've switched over to a regular recurring
> analysis.
>
> Happy holidays,
> Brian
>
>
>> From: Brian Chess <brian@fortifysoftware.com>
>> Date: Mon, 18 Dec 2006 21:16:06 -0800
>> To: <java-dev@lucene.apache.org>
>> Conversation: access policy for Java Open Review Project
>> Subject: access policy for Java Open Review Project
>>
>> Hi all, I've been busy creating JOR accounts this weekend, and it  
>> was cool to
>> see so many names from Lucene.  Lucene, Solr, and Nutch have the  
>> lowest defect
>> rates among the projects we've looked at, and I'm beginning to see  
>> why.
>>
>> One of the things JOR is doing is inviting people to come and help  
>> review
>> issues we find with static analysis.  We've had a fair number of  
>> signups
>> since the project was on slashdot.
>>
>> My question is, would you like to allow outsiders to go through  
>> results and
>> help sort the real bugs from the chaff?  The upside is that  
>> volunteers may
>> perform useful work and that it may be another avenue to get  
>> people involved
>> with the code.  The down side is that things like XSS in admin  
>> pages may lead
>> them to make more ruckus than is really appropriate.
>>
>> The situation may change if we can establish a mechanism for  
>> efficiently
>> moving issues into Jira, but for now, I could imagine a number of  
>> different
>> policies, including:
>>   - Allow anyone access who asks for it.
>>   - Allow access on a case-by-case basis.
>>   - Don't allow access to outsiders.
>>
>> Here are the "outsiders" who've requested access so far, along  
>> with a few
>> words to summarize what they've told me about themselves.
>>
>> Lucene
>> ------
>> Varun Nair <varun.nair@tcs.com>: budding code auditor at TCS
>> Martin Englund <martin.englund@sun.com>: Experienced auditor at Sun
>> gfua@caramail.com: Looks like he's just testing the waters
>>
>> Lucene, Nutch, Solr
>> ------
>> Thierry De Leeuw <thierry@avanco.be>: experienced vulnerability  
>> hunter
>> Michael Bunzel <mrb@lintranex.com>: experienced auditor, but new to
>>                                     auditing Java
>>
>> Thoughts?
>> Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message