Re: access policy for Java Open Review Project
On Wednesday 27 December 2006 01:38, Erik Hatcher wrote: I'd be surprised if anyone uses Lucli, given the limited utility it has versus using Luke. It's actually very useful if you only have ssh access to a machine that has no X11 running. I just fixed the small bug found by this review. Regards Daniel -- http://www.danielnaber.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access policy for Java Open Review Project
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: budding code auditor at TCS Martin Englund [EMAIL PROTECTED]: Experienced auditor at Sun [EMAIL PROTECTED]: Looks like he's just testing the waters Lucene, Nutch, Solr -- Thierry De Leeuw [EMAIL PROTECTED]: experienced vulnerability hunter Michael Bunzel [EMAIL PROTECTED]: experienced auditor, but new to auditing Java Thoughts? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access policy for Java Open Review Project
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: budding code auditor at TCS Martin Englund [EMAIL PROTECTED]: Experienced auditor at Sun [EMAIL PROTECTED]: Looks like he's just testing the waters Lucene, Nutch, Solr -- Thierry De Leeuw [EMAIL PROTECTED]: experienced vulnerability hunter Michael Bunzel [EMAIL PROTECTED]: experienced auditor, but new to auditing Java Thoughts? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access policy for Java Open Review Project
On Dec 19, 2006, at 12:16 AM, Brian Chess wrote: 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. Are there any security concerns (I think your original intro said you don't generally share w/ the public) of having others involved? That is, could we be publishing information that could make a Lucene application vulnerable or is really just a ruckus issue? Part of me thinks that b/c the code is freely available, people could find the security issues anyway, so we aren't really protecting ourselves anyway by denying access. Thanks, btw, for the account and for setting this up. -- Grant Ingersoll Center for Natural Language Processing http://www.cnlp.org Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/ LuceneFAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access policy for Java Open Review Project
Brian Chess wrote: My question is, would you like to allow outsiders to go through results and help sort the real bugs from the chaff? That's up to you. It's your service, not governed by the Apache Lucene project. If you cause your system to add reasonable issues to our bug-tracking system, then we will take over from there. If you wish to provide a free service that we administer, then the project should vote to decide whether it wants to take on that duty. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]: budding code auditor at TCS Martin Englund [EMAIL PROTECTED]: Experienced auditor at Sun [EMAIL PROTECTED]: Looks like he's just testing the waters Lucene, Nutch, Solr -- Thierry De Leeuw [EMAIL PROTECTED]: experienced vulnerability hunter Michael Bunzel [EMAIL PROTECTED]: experienced auditor, but new to auditing Java Thoughts? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
