Re: Outstanding issues for 3.0.3
Nowadays git works just great for Windows, and it's much easier to work with than Hg On Wed, Aug 1, 2012 at 9:41 PM, Zachary Gramana zgram...@feature23.comwrote: On Aug 1, 2012, at 12:51 PM, Itamar Syn-Hershko wrote: And for heaven's sake, can we move to git when graduating? Given that we're a .NET-focused community, and many of us are likely primarily using Windows as both our primary development and deployment platforms, I'd suggest looking at Mercurial before committing to git. Either way, +1 for any DVCS.
Re: Outstanding issues for 3.0.3
fork it and git r done? I couldn't resist. +1 for git. On Thu, Aug 2, 2012 at 3:04 AM, Itamar Syn-Hershko ita...@code972.comwrote: Nowadays git works just great for Windows, and it's much easier to work with than Hg On Wed, Aug 1, 2012 at 9:41 PM, Zachary Gramana zgram...@feature23.com wrote: On Aug 1, 2012, at 12:51 PM, Itamar Syn-Hershko wrote: And for heaven's sake, can we move to git when graduating? Given that we're a .NET-focused community, and many of us are likely primarily using Windows as both our primary development and deployment platforms, I'd suggest looking at Mercurial before committing to git. Either way, +1 for any DVCS.
Re: Outstanding issues for 3.0.3
I would like to pitch into this effort and put my ReSharper license to use. I pulled down trunk, and picked a yellow item at random, and started to dig in. I quickly generated more questions than answers, realized I needed to stop munging code and consult the wiki and list archives. After digging through both, I'm still not entirely certain about what the style guidelines are for 3.x onward. I also noted this[1] discussion regarding some other guidelines, but it didn't see if it made it beyond the proposal stage. [1] http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3ccajtrbsrdbzkocwln6d6ywhzn2fno91mko1acrp-pflx62du...@mail.gmail.com%3E Here are some of the things Re# is catching that I'm unsure of: 1) Usage of this prefix when not required. this.blah = blah; - required this. this.aBlah = blah; - optional this, which Re# doesn't like. I'm assuming consistency wins here, and 'this.' stays, but wanted to double check. 2) Using different conventions for fields and parameters\local vars. blah vs. _blah Combined with 1, Re# wants (and I'm personally accustomed to): _blah = blah; However, that seems to violate the adopted style. 3) Full qualification of type names. Re # wants to remove redundant namespace qualifiers. Leave them or remove them? 4) Removing unreferenced classes. Should I remove non-public unreferenced classes? The ones I've come across so far are private. 5) var vs. explicit I know this has been brought up before, but not sure of the final disposition. FWIW, I prefer var. There are some non-Re# issues I came across as well that look like artifacts of code generation: 6) Weird param names. Param1 vs. directory I assume it's okay to replace 'Param1' with something a descriptive name like 'directory'. 7) Field names that follow local variable naming conventions. Lots of issues related to private vars with names like i, j, k, etc. It feels like the right thing to do is to change the scope so that they go back to being local vars instead of fields. However, this requires a much more significant refactoring, and I didn't want to assume it was okay to do that. If these questions have already been answered elsewhere and I missed the documentation/FAQ/developer guide, then I apologize and would appreciate the links. Alternatively, if someone has a Re# rule config that they are willing to post somewhere, I would be glad to use it. - Zack On Jul 27, 2012, at 12:00 PM, Itamar Syn-Hershko wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it).
RE: Outstanding issues for 3.0.3
https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3 Please update the wiki and the changes.TXT file with any changes you're aware of - I will take some time this weekend to comb through everything and add whatever is missing From: geobmx...@hotmail.com To: lucene-net-dev@lucene.apache.org Subject: RE: Outstanding issues for 3.0.3 Date: Thu, 2 Aug 2012 09:13:12 -0700 I don't think we ever fully adopted the style guidelines, probably not a terrible discussion to have. As for this release, I think that by lazy consensus we should branch the trunk at the end of this weekend (say monday), and begin the process of cutting a release. - my $.02 below 1) Usage of this prefix when not required. this.blah = blah; - required this. this.aBlah = blah; - optional this, which Re# doesn't like. I'm assuming consistency wins here, and 'this.' stays, but wanted to double check. I'd error with consistency 2) Using different conventions for fields and parameters\local vars. blah vs. _blah Combined with 1, Re# wants (and I'm personally accustomed to): _blah = blah; For private variables _ is ok, for anything else, don't use _ as it's not CLR compliant However, that seems to violate the adopted style. 3) Full qualification of type names. Re # wants to remove redundant namespace qualifiers. Leave them or remove them? I try to remove them 4) Removing unreferenced classes. Should I remove non-public unreferenced classes? The ones I've come across so far are private. I'm not sure I understand - are you saying we have classes that are never used in random places? If so, I think before removing them we should have a conversation; what are they, why are they there, etc. - I'm hoping there aren't too many of these.. 5) var vs. explicit I know this has been brought up before, but not sure of the final disposition. FWIW, I prefer var. I use var with it's plainly obvious the object var obj = new MyClass(). I usually use explicit when it's an object returned from some function that makes it unclear what the return value is: var items = search.GetResults(); vs IListSearchResult items = search.GetResults(); //prefer There are some non-Re# issues I came across as well that look like artifacts of code generation: 6) Weird param names. Param1 vs. directory I assume it's okay to replace 'Param1' with something a descriptive name like 'directory'. Weird - I think a rename is OK for this release (Since we're ticking up a full version number), but I believe changing param names can potentially break code. That said, I don't really think we need to change the names and push the 3.0.3 release out, and if it does in fact cause breaking changes, I'd be a little careful about how we do it going forward to 3.6. 7) Field names that follow local variable naming conventions. Lots of issues related to private vars with names like i, j, k, etc. It feels like the right thing to do is to change the scope so that they go back to being local vars instead of fields. However, this requires a much more significant refactoring, and I didn't want to assume it was okay to do that. I'd avoid this for now - a lot of this is a carry over from the java version and to rename all those, it starts to get a bit confusing if we have to compare java to C# and these are all changed around. If these questions have already been answered elsewhere and I missed the documentation/FAQ/developer guide, then I apologize and would appreciate the links. Alternatively, if someone has a Re# rule config that they are willing to post somewhere, I would be glad to use it. I think we talked about Re#'s rules at one point, I'll try to dig that conversation up and see where it landed. It's probably a good idea for us to build rules though. - Zack On Jul 27, 2012, at 12:00 PM, Itamar Syn-Hershko wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it).
Re: Outstanding issues for 3.0.3
The point is to make the code better, not to satisfy R# :) The main benefit of this process is marking fields as readonly, finding code paths with stupid behavior and moving simple aggregations to use LINQ. I don't apply the LINQ syntax to a non-trivial operations, to make it easier to keep track of the Java version. My thoughts on the points you raised inline On Thu, Aug 2, 2012 at 6:53 PM, Zachary Gramana zgram...@gmail.com wrote: I would like to pitch into this effort and put my ReSharper license to use. I pulled down trunk, and picked a yellow item at random, and started to dig in. I quickly generated more questions than answers, realized I needed to stop munging code and consult the wiki and list archives. After digging through both, I'm still not entirely certain about what the style guidelines are for 3.x onward. I also noted this[1] discussion regarding some other guidelines, but it didn't see if it made it beyond the proposal stage. [1] http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3ccajtrbsrdbzkocwln6d6ywhzn2fno91mko1acrp-pflx62du...@mail.gmail.com%3E Here are some of the things Re# is catching that I'm unsure of: 1) Usage of this prefix when not required. this.blah = blah; - required this. this.aBlah = blah; - optional this, which Re# doesn't like. I'm assuming consistency wins here, and 'this.' stays, but wanted to double check. Doesn't really matter IMO. I just hit Alt-enter when I have it in focus, otherwise I ignore that. 2) Using different conventions for fields and parameters\local vars. blah vs. _blah Combined with 1, Re# wants (and I'm personally accustomed to): _blah = blah; However, that seems to violate the adopted style. I think we should stick to the Java naming conventions in the private parts (minus the function casings) as much as possible. Main reason is the ability to apply patches from Java Lucene and support future ports more easily. This is why I kept variable names untouched. 3) Full qualification of type names. Re # wants to remove redundant namespace qualifiers. Leave them or remove them? Same as Alt-Enter argument as above... 4) Removing unreferenced classes. Should I remove non-public unreferenced classes? The ones I've come across so far are private. It's .NET, not C++, but I still usually remove them, not really sure why tho... 5) var vs. explicit I know this has been brought up before, but not sure of the final disposition. FWIW, I prefer var. There are some non-Re# issues I came across as well that look like artifacts of code generation: I move to var because it *might* help in the future when the API changes, and it doesn't really affect anything now 6) Weird param names. Param1 vs. directory I assume it's okay to replace 'Param1' with something a descriptive name like 'directory'. Yes. Also var names like out_Renamed to @out. This one is important. 7) Field names that follow local variable naming conventions. Lots of issues related to private vars with names like i, j, k, etc. It feels like the right thing to do is to change the scope so that they go back to being local vars instead of fields. However, this requires a much more significant refactoring, and I didn't want to assume it was okay to do that. See above, I don't think we should touch those. If these questions have already been answered elsewhere and I missed the documentation/FAQ/developer guide, then I apologize and would appreciate the links. Alternatively, if someone has a Re# rule config that they are willing to post somewhere, I would be glad to use it. - Zack On Jul 27, 2012, at 12:00 PM, Itamar Syn-Hershko wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it).
Re: Outstanding issues for 3.0.3
Prescott - we could make an RC and push it to Nuget as a PreRelease, to get real feedback. On Thu, Aug 2, 2012 at 7:13 PM, Prescott Nasser geobmx...@hotmail.comwrote: I don't think we ever fully adopted the style guidelines, probably not a terrible discussion to have. As for this release, I think that by lazy consensus we should branch the trunk at the end of this weekend (say monday), and begin the process of cutting a release. - my $.02 below 1) Usage of this prefix when not required. this.blah = blah; - required this. this.aBlah = blah; - optional this, which Re# doesn't like. I'm assuming consistency wins here, and 'this.' stays, but wanted to double check. I'd error with consistency 2) Using different conventions for fields and parameters\local vars. blah vs. _blah Combined with 1, Re# wants (and I'm personally accustomed to): _blah = blah; For private variables _ is ok, for anything else, don't use _ as it's not CLR compliant However, that seems to violate the adopted style. 3) Full qualification of type names. Re # wants to remove redundant namespace qualifiers. Leave them or remove them? I try to remove them 4) Removing unreferenced classes. Should I remove non-public unreferenced classes? The ones I've come across so far are private. I'm not sure I understand - are you saying we have classes that are never used in random places? If so, I think before removing them we should have a conversation; what are they, why are they there, etc. - I'm hoping there aren't too many of these.. 5) var vs. explicit I know this has been brought up before, but not sure of the final disposition. FWIW, I prefer var. I use var with it's plainly obvious the object var obj = new MyClass(). I usually use explicit when it's an object returned from some function that makes it unclear what the return value is: var items = search.GetResults(); vs IListSearchResult items = search.GetResults(); //prefer There are some non-Re# issues I came across as well that look like artifacts of code generation: 6) Weird param names. Param1 vs. directory I assume it's okay to replace 'Param1' with something a descriptive name like 'directory'. Weird - I think a rename is OK for this release (Since we're ticking up a full version number), but I believe changing param names can potentially break code. That said, I don't really think we need to change the names and push the 3.0.3 release out, and if it does in fact cause breaking changes, I'd be a little careful about how we do it going forward to 3.6. 7) Field names that follow local variable naming conventions. Lots of issues related to private vars with names like i, j, k, etc. It feels like the right thing to do is to change the scope so that they go back to being local vars instead of fields. However, this requires a much more significant refactoring, and I didn't want to assume it was okay to do that. I'd avoid this for now - a lot of this is a carry over from the java version and to rename all those, it starts to get a bit confusing if we have to compare java to C# and these are all changed around. If these questions have already been answered elsewhere and I missed the documentation/FAQ/developer guide, then I apologize and would appreciate the links. Alternatively, if someone has a Re# rule config that they are willing to post somewhere, I would be glad to use it. I think we talked about Re#'s rules at one point, I'll try to dig that conversation up and see where it landed. It's probably a good idea for us to build rules though. - Zack On Jul 27, 2012, at 12:00 PM, Itamar Syn-Hershko wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it).
RE: Outstanding issues for 3.0.3
Excellent Idea - I'll do that monday to give you guys the weekend to do any last minute code cleaning you want. Date: Thu, 2 Aug 2012 19:30:02 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Prescott - we could make an RC and push it to Nuget as a PreRelease, to get real feedback. On Thu, Aug 2, 2012 at 7:13 PM, Prescott Nasser geobmx...@hotmail.comwrote: I don't think we ever fully adopted the style guidelines, probably not a terrible discussion to have. As for this release, I think that by lazy consensus we should branch the trunk at the end of this weekend (say monday), and begin the process of cutting a release. - my $.02 below 1) Usage of this prefix when not required. this.blah = blah; - required this. this.aBlah = blah; - optional this, which Re# doesn't like. I'm assuming consistency wins here, and 'this.' stays, but wanted to double check. I'd error with consistency 2) Using different conventions for fields and parameters\local vars. blah vs. _blah Combined with 1, Re# wants (and I'm personally accustomed to): _blah = blah; For private variables _ is ok, for anything else, don't use _ as it's not CLR compliant However, that seems to violate the adopted style. 3) Full qualification of type names. Re # wants to remove redundant namespace qualifiers. Leave them or remove them? I try to remove them 4) Removing unreferenced classes. Should I remove non-public unreferenced classes? The ones I've come across so far are private. I'm not sure I understand - are you saying we have classes that are never used in random places? If so, I think before removing them we should have a conversation; what are they, why are they there, etc. - I'm hoping there aren't too many of these.. 5) var vs. explicit I know this has been brought up before, but not sure of the final disposition. FWIW, I prefer var. I use var with it's plainly obvious the object var obj = new MyClass(). I usually use explicit when it's an object returned from some function that makes it unclear what the return value is: var items = search.GetResults(); vs IListSearchResult items = search.GetResults(); //prefer There are some non-Re# issues I came across as well that look like artifacts of code generation: 6) Weird param names. Param1 vs. directory I assume it's okay to replace 'Param1' with something a descriptive name like 'directory'. Weird - I think a rename is OK for this release (Since we're ticking up a full version number), but I believe changing param names can potentially break code. That said, I don't really think we need to change the names and push the 3.0.3 release out, and if it does in fact cause breaking changes, I'd be a little careful about how we do it going forward to 3.6. 7) Field names that follow local variable naming conventions. Lots of issues related to private vars with names like i, j, k, etc. It feels like the right thing to do is to change the scope so that they go back to being local vars instead of fields. However, this requires a much more significant refactoring, and I didn't want to assume it was okay to do that. I'd avoid this for now - a lot of this is a carry over from the java version and to rename all those, it starts to get a bit confusing if we have to compare java to C# and these are all changed around. If these questions have already been answered elsewhere and I missed the documentation/FAQ/developer guide, then I apologize and would appreciate the links. Alternatively, if someone has a Re# rule config that they are willing to post somewhere, I would be glad to use it. I think we talked about Re#'s rules at one point, I'll try to dig that conversation up and see where it landed. It's probably a good idea for us to build rules though. - Zack On Jul 27, 2012, at 12:00 PM, Itamar Syn-Hershko wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it).
Re: Outstanding issues for 3.0.3
I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.comwrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com
Re: Outstanding issues for 3.0.3
Ah, I did overlook that. I imagine that the move from 3.0.3 to 3.6 will realistically take a while, so if we can't get spatial stuff out before then, would it take until 3.6 to be able to release new functionality into the spatial contrib project? Along those lines, I propose that we move 3.0.3 into a new branch instead of just tagging the release and merging in 3.6. That way, during the time it takes to port 3.6, we can still do any critical bug fixes and features like these and release new versions. At least then, people won't be waiting for months for bug fixes. If we did that, then it also might not be critical to get the spatial stuff out with this release, since we could get out a new release in a few weeks with updated spatial libraries...not that I'm against waiting for it now. It was just a suggestion on how we can move forward with the project. Thoughts either way on this? On Wed, Aug 1, 2012 at 9:31 AM, Itamar Syn-Hershko ita...@code972.comwrote: I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com
Re: Outstanding issues for 3.0.3
+1 from me too, then On Wed, Aug 1, 2012 at 7:42 PM, Prescott Nasser geobmx...@hotmail.comwrote: Spatial could be something cool to look forward to in 3.6 IMO. I'm good with tagging what we have and I'd like to take a week to allow the community test the tag code against their stuff before cutting release binaries. +1 to going now. Date: Wed, 1 Aug 2012 19:31:45 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we
RE: Outstanding issues for 3.0.3
That's probably not a bad idea - we should probably move to a structure like that anyway going forward so that it's easier to manage bug fixes and minor updates in between the big work Date: Wed, 1 Aug 2012 09:42:40 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org Ah, I did overlook that. I imagine that the move from 3.0.3 to 3.6 will realistically take a while, so if we can't get spatial stuff out before then, would it take until 3.6 to be able to release new functionality into the spatial contrib project? Along those lines, I propose that we move 3.0.3 into a new branch instead of just tagging the release and merging in 3.6. That way, during the time it takes to port 3.6, we can still do any critical bug fixes and features like these and release new versions. At least then, people won't be waiting for months for bug fixes. If we did that, then it also might not be critical to get the spatial stuff out with this release, since we could get out a new release in a few weeks with updated spatial libraries...not that I'm against waiting for it now. It was just a suggestion on how we can move forward with the project. Thoughts either way on this? On Wed, Aug 1, 2012 at 9:31 AM, Itamar Syn-Hershko ita...@code972.comwrote: I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I
Re: Outstanding issues for 3.0.3
Yes, we could also release a 3.0.10 or something with the improved spatial module. Or I can race Prescott's week and get it in before it ends :) And for heaven's sake, can we move to git when graduating? A live crash course to all committers is on me. On Wed, Aug 1, 2012 at 7:42 PM, Christopher Currens currens.ch...@gmail.com wrote: Ah, I did overlook that. I imagine that the move from 3.0.3 to 3.6 will realistically take a while, so if we can't get spatial stuff out before then, would it take until 3.6 to be able to release new functionality into the spatial contrib project? Along those lines, I propose that we move 3.0.3 into a new branch instead of just tagging the release and merging in 3.6. That way, during the time it takes to port 3.6, we can still do any critical bug fixes and features like these and release new versions. At least then, people won't be waiting for months for bug fixes. If we did that, then it also might not be critical to get the spatial stuff out with this release, since we could get out a new release in a few weeks with updated spatial libraries...not that I'm against waiting for it now. It was just a suggestion on how we can move forward with the project. Thoughts either way on this? On Wed, Aug 1, 2012 at 9:31 AM, Itamar Syn-Hershko ita...@code972.com wrote: I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free
Re: Outstanding issues for 3.0.3
On that note, see git-flow http://nvie.com/posts/a-successful-git-branching-model/ :) On Wed, Aug 1, 2012 at 7:49 PM, Prescott Nasser geobmx...@hotmail.comwrote: That's probably not a bad idea - we should probably move to a structure like that anyway going forward so that it's easier to manage bug fixes and minor updates in between the big work Date: Wed, 1 Aug 2012 09:42:40 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org Ah, I did overlook that. I imagine that the move from 3.0.3 to 3.6 will realistically take a while, so if we can't get spatial stuff out before then, would it take until 3.6 to be able to release new functionality into the spatial contrib project? Along those lines, I propose that we move 3.0.3 into a new branch instead of just tagging the release and merging in 3.6. That way, during the time it takes to port 3.6, we can still do any critical bug fixes and features like these and release new versions. At least then, people won't be waiting for months for bug fixes. If we did that, then it also might not be critical to get the spatial stuff out with this release, since we could get out a new release in a few weeks with updated spatial libraries...not that I'm against waiting for it now. It was just a suggestion on how we can move forward with the project. Thoughts either way on this? On Wed, Aug 1, 2012 at 9:31 AM, Itamar Syn-Hershko ita...@code972.com wrote: I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up
Re: Outstanding issues for 3.0.3
On Aug 1, 2012, at 12:51 PM, Itamar Syn-Hershko wrote: And for heaven's sake, can we move to git when graduating? Given that we're a .NET-focused community, and many of us are likely primarily using Windows as both our primary development and deployment platforms, I'd suggest looking at Mercurial before committing to git. Either way, +1 for any DVCS.
RE: Outstanding issues for 3.0.3
Did I miss the email where Itamar actually said And for heaven's sake, can we move to git when graduating? I think I did. I'll add it to the list of things to discuss as we progress. I believe we discussed this in the past and at the time we had a lazy consensus to stick with svn. Subject: Re: Outstanding issues for 3.0.3 From: zgram...@feature23.com Date: Wed, 1 Aug 2012 14:41:28 -0400 To: lucene-net-dev@lucene.apache.org On Aug 1, 2012, at 12:51 PM, Itamar Syn-Hershko wrote: And for heaven's sake, can we move to git when graduating? Given that we're a .NET-focused community, and many of us are likely primarily using Windows as both our primary development and deployment platforms, I'd suggest looking at Mercurial before committing to git. Either way, +1 for any DVCS.
Re: Outstanding issues for 3.0.3
Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against
Re: Outstanding issues for 3.0.3
Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org
Re: Outstanding issues for 3.0.3
I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.comwrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have
RE: Outstanding issues for 3.0.3
Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.comwrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close
Re: Outstanding issues for 3.0.3
Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several
RE: Outstanding issues for 3.0.3
Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues
Re: Outstanding issues for 3.0.3
I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.comwrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close it out. Thanks, Christopher On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson si...@devhost.se wrote: The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/**jira/browse/LUCENENET-456 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/**jira/browse/LUCENENET-446 https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/**jira/browse/LUCENENET-470 https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6. With CLS compliance we have to ask if we've done enough for that so far, or if more is needed. I personally would like to see us make any API changes now, with the 3.0.3 release, but if we are comfortable with it, lets roll. What are your thoughts? ~P --**-- From: thowar...@gmail.com Date: Mon, 25 Jun 2012 10:34:37 -0700 Subject: Re: Outstanding issues for 3.0.3 To: lucene-net-dev
RE: Outstanding issues for 3.0.3
What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.comwrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close it out. Thanks, Christopher On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson si...@devhost.se wrote: The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/**jira/browse/LUCENENET-456 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/**jira/browse/LUCENENET-446 https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/**jira/browse/LUCENENET-470 https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6
Re: Outstanding issues for 3.0.3
I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.comwrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the 3.5 framework. Anyone have experience with multi-targeting like this? Thanks, Christopher On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser geobmx...@hotmail.com wrote: Have at it. Date: Mon, 9 Jul 2012 11:20:06 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org If it's alright with you, I'll work on it a little bit in that branch, and see what kind of progress I can make, since I have some time right now. On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser geobmx...@hotmail.com wrote: I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close it out. Thanks, Christopher On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson si...@devhost.se wrote: The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/**jira/browse/LUCENENET-456 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/**jira/browse
RE: Outstanding issues for 3.0.3
Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6. With CLS compliance we have to ask if we've done enough for that so far, or if more is needed. I personally would like to see us make any API changes now, with the 3.0.3 release, but if we are comfortable with it, lets roll. What are your thoughts? ~P From: thowar...@gmail.com Date: Mon, 25 Jun 2012 10:34:37 -0700 Subject: Re: Outstanding issues for 3.0.3 To: lucene-net-dev@lucene.apache.org Assuming we're talking about the packaging/filesystem structure in the releases, the structure is a little of both (ours vs Apache's)... Basically, I went through most of the Apache projects to see how they packaged releases and developed a structure that was very similar but encompassed everything we needed. So, it's informed by the organically emergent structures that ASF uses. -T On Mon, Jun 25, 2012 at 7:32 AM, Prescott Nasser geobmx...@hotmail.com wrote: I have no idea why I thought we were using Nant. I think it's just our release structure. I figured a little out this weekend, splitting the XML and .dll files into separate directories. The documentation you have on the wiki was actually pretty helpful. Whatever more you can add would be great ~P Date: Mon, 25 Jun 2012 10:04:21 -0400 Subject: Re: Outstanding issues for 3.0.3 From: mhern...@wickedsoftware.net To: lucene-net-dev@lucene.apache.org On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser geobmx...@hotmail.comwrote: -- Task 470, a non-serious one, is listed only because it's mostly done and just need a few loose ends tied up. I'll hopefully have time to take care of that this weekend. How many GetX/SetX are left? I did a quick search for 'public * Get*()' Most of them looked to be actual methods - perhaps a few to replace -- Task 446 (CLS Compliance), is important, but there's no way we can get this done quickly. The current state of this issue is that all of the names of public members are now compliant. There are a few things that aren't, the use of sbyte (particularly those related to the FieldCache) and some conflicts with *protected or internal* fields (some with public members). Opinions on this one will be appreciated the most. My opinion is that we should draw a line on the amount of CLS compliance to have in this release, and push the rest into 3.5. I count roughly 53 CLS compliant issues. the sbyte stuff will run into trouble when you do bit shifting (I ran into this issue when trying to do this for 2.9.4. I'd like to see if we can't get rid of the easier stuff (internal/protected stuff). I would not try getting rid of sbyte or volatile for thile release. It's going to take some serious consideration to get rid of those -- Improvement 337 - Are we going to add this code (not present in java) to the core library? I'd skip it and re-evaluate the community desire for this in 3.5. -- Improvement 456 - This is related to builds being output in Apache's release format. Do we want to do this for this release? I looked into this last weekend - I'm terrible with Nant, so I didn't get anywhere. It would be nice to have, but I don't think I'll figure it out. If Michael has some time to maybe make the adjustment, he knows these scripts best. If not I'm going to look into it, but I don't call this a show stopper - either we have it or we don't when the rest is done. With some Flo Rida and expresso shots, anything is possible. Did we switch to Nant? I saw the jira ticket for this. Is there an official apache release structure or this just our* apache release structure that we are using? Can I take the latest release and use that to model the structure you guys want? @Prescott declarative xml build scripts are a pita in general. only reason we're using this over powershell or a scripting language is that mono supports it and most .NET devs have it already
Re: Outstanding issues for 3.0.3
What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.comwrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6. With CLS compliance we have to ask if we've done enough for that so far, or if more is needed. I personally would like to see us make any API changes now, with the 3.0.3 release, but if we are comfortable with it, lets roll. What are your thoughts? ~P From: thowar...@gmail.com Date: Mon, 25 Jun 2012 10:34:37 -0700 Subject: Re: Outstanding issues for 3.0.3 To: lucene-net-dev@lucene.apache.org Assuming we're talking about the packaging/filesystem structure in the releases, the structure is a little of both (ours vs Apache's)... Basically, I went through most of the Apache projects to see how they packaged releases and developed a structure that was very similar but encompassed everything we needed. So, it's informed by the organically emergent structures that ASF uses. -T On Mon, Jun 25, 2012 at 7:32 AM, Prescott Nasser geobmx...@hotmail.com wrote: I have no idea why I thought we were using Nant. I think it's just our release structure. I figured a little out this weekend, splitting the XML and .dll files into separate directories. The documentation you have on the wiki was actually pretty helpful. Whatever more you can add would be great ~P Date: Mon, 25 Jun 2012 10:04:21 -0400 Subject: Re: Outstanding issues for 3.0.3 From: mhern...@wickedsoftware.net To: lucene-net-dev@lucene.apache.org On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser geobmx...@hotmail.comwrote: -- Task 470, a non-serious one, is listed only because it's mostly done and just need a few loose ends tied up. I'll hopefully have time to take care of that this weekend. How many GetX/SetX are left? I did a quick search for 'public * Get*()' Most of them looked to be actual methods - perhaps a few to replace -- Task 446 (CLS Compliance), is important, but there's no way we can get this done quickly. The current state of this issue is that all of the names of public members are now compliant. There are a few things that aren't, the use of sbyte (particularly those related to the FieldCache) and some conflicts with *protected or internal* fields (some with public members). Opinions on this one will be appreciated the most. My opinion is that we should draw a line on the amount of CLS compliance to have in this release, and push the rest into 3.5. I count roughly 53 CLS compliant issues. the sbyte stuff will run into trouble when you do bit shifting (I ran into this issue when trying to do this for 2.9.4. I'd like to see if we can't get rid of the easier stuff (internal/protected stuff). I would not try getting rid of sbyte or volatile for thile release. It's going to take some serious consideration to get rid of those -- Improvement 337 - Are we going to add this code (not present in java) to the core library? I'd skip it and re-evaluate the community desire for this in 3.5. -- Improvement 456 - This is related to builds being output in Apache's release format. Do we want to do this for this release? I looked into this last weekend - I'm terrible with Nant, so I didn't get anywhere. It would be nice to have, but I don't think I'll figure it out. If Michael has some time to maybe make the adjustment, he knows these scripts best. If not I'm going to look into it, but I don't call this a show stopper - either we have it or we don't when the rest is done. With some Flo Rida and expresso shots, anything is possible. Did we switch to Nant? I saw the jira ticket for this. Is there an official apache release structure or this just our* apache release structure that we are using? Can I take the latest release and use that to model the structure you
Re: Outstanding issues for 3.0.3
The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.comwrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6. With CLS compliance we have to ask if we've done enough for that so far, or if more is needed. I personally would like to see us make any API changes now, with the 3.0.3 release, but if we are comfortable with it, lets roll. What are your thoughts? ~P From: thowar...@gmail.com Date: Mon, 25 Jun 2012 10:34:37 -0700 Subject: Re: Outstanding issues for 3.0.3 To: lucene-net-dev@lucene.apache.org Assuming we're talking about the packaging/filesystem structure in the releases, the structure is a little of both (ours vs Apache's)... Basically, I went through most of the Apache projects to see how they packaged releases and developed a structure that was very similar but encompassed everything we needed. So, it's informed by the organically emergent structures that ASF uses. -T On Mon, Jun 25, 2012 at 7:32 AM, Prescott Nasser geobmx...@hotmail.com wrote: I have no idea why I thought we were using Nant. I think it's just our release structure. I figured a little out this weekend, splitting the XML and .dll files into separate directories. The documentation you have on the wiki was actually pretty helpful. Whatever more you can add would be great ~P Date: Mon, 25 Jun 2012 10:04:21 -0400 Subject: Re: Outstanding issues for 3.0.3 From: mhern...@wickedsoftware.net To: lucene-net-dev@lucene.apache.org On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser geobmx...@hotmail.comwrote: -- Task 470, a non-serious one, is listed only because it's mostly done and just need a few loose ends tied up. I'll hopefully have time to take care of that this weekend. How many GetX/SetX are left? I did a quick search for 'public * Get*()' Most of them looked to be actual methods - perhaps a few to replace -- Task 446 (CLS Compliance), is important, but there's no way we can get this done quickly. The current state of this issue is that all of the names of public members are now compliant. There are a few things that aren't, the use of sbyte (particularly those related to the FieldCache) and some conflicts with *protected or internal* fields (some with public members). Opinions on this one will be appreciated the most. My opinion is that we should draw a line on the amount of CLS compliance to have in this release, and push the rest into 3.5. I count roughly 53 CLS compliant issues. the sbyte stuff will run into trouble when you do bit shifting (I ran into this issue when trying to do this for 2.9.4. I'd like to see if we can't get rid of the easier stuff (internal/protected stuff). I would not try getting rid of sbyte or volatile for thile release. It's going to take some serious consideration to get rid of those -- Improvement 337 - Are we going to add this code (not present in java) to the core library? I'd skip it and re-evaluate the community desire for this in 3.5. -- Improvement 456 - This is related to builds being output in Apache's release format. Do we want to do this for this release? I looked into this last weekend - I'm terrible with Nant, so I didn't get anywhere. It would be nice to have, but I don't think I'll figure it out. If Michael has some time to maybe make the adjustment, he knows these scripts best. If not I'm going to look into it, but I don't call this a show stopper - either we have it or we don't when the rest is done. With some Flo Rida and expresso shots, anything is possible. Did we switch to Nant? I saw the jira ticket for this. Is there an official apache release structure or this just our* apache release structure that we are using? Can I take the latest release and use that to model the structure you guys want? @Prescott declarative xml build scripts are a pita in general. only reason we're using this over powershell or a scripting language is that mono supports
RE: Outstanding issues for 3.0.3
-- Task 470, a non-serious one, is listed only because it's mostly done and just need a few loose ends tied up. I'll hopefully have time to take care of that this weekend. How many GetX/SetX are left? I did a quick search for 'public * Get*()' Most of them looked to be actual methods - perhaps a few to replace -- Task 446 (CLS Compliance), is important, but there's no way we can get this done quickly. The current state of this issue is that all of the names of public members are now compliant. There are a few things that aren't, the use of sbyte (particularly those related to the FieldCache) and some conflicts with *protected or internal* fields (some with public members). Opinions on this one will be appreciated the most. My opinion is that we should draw a line on the amount of CLS compliance to have in this release, and push the rest into 3.5. I count roughly 53 CLS compliant issues. the sbyte stuff will run into trouble when you do bit shifting (I ran into this issue when trying to do this for 2.9.4. I'd like to see if we can't get rid of the easier stuff (internal/protected stuff). I would not try getting rid of sbyte or volatile for thile release. It's going to take some serious consideration to get rid of those -- Improvement 337 - Are we going to add this code (not present in java) to the core library? I'd skip it and re-evaluate the community desire for this in 3.5. -- Improvement 456 - This is related to builds being output in Apache's release format. Do we want to do this for this release? I looked into this last weekend - I'm terrible with Nant, so I didn't get anywhere. It would be nice to have, but I don't think I'll figure it out. If Michael has some time to maybe make the adjustment, he knows these scripts best. If not I'm going to look into it, but I don't call this a show stopper - either we have it or we don't when the rest is done. ~P
