On Sun, Jan 8, 2012 at 1:36 PM, Simon Willnauer <[email protected]> wrote: >> >> From the tests/bugfixing perspective, on trunk its not hard to dig >> into stuff here and there and find lots of really horrible bugs that >> exist in trunk-only. This is a sign that our tests are not good enough >> and that the code is not stable enough. > > I don't understand this entirely, can you elaborate? if there are > horrible bugs there should be issues marked as blocker. >
Well maybe I delivered this idea the wrong way: i didn't mean i secretly know of any bugs or anything like that: I just mean as a trend, recently over the last few months I have noticed lots of bugs that only affect 4.x but don't affect 3.x I think this is natural, a lot has changed, but to mitigate that we need to beef up tests and spend more time reviewing and trying to clean up. I'm just as guilty as anyone else when it comes to these changes without having adequate tests. > > I did ask to push the release tomorrow. I personally feel some > frustration that lucene 4 is still not released and I think we are > really close. I'm pretty frustrated working on some code for years that is unreleased. > From my perspective we should build some kind of roadmap > to get lucene 4 or a beta out lets say within the next 2 month and > concentrate on getting the remaining issues resolved. We should > collect issues and problems and mark them as blockers so we can pick > them up and get it out of the door. Right now all the issues you > listed are somewhat known but there is no way to access them, I > suggest we open JIRA ticket and decide issue per issue if they are > blockers or not. I do think we need some kind of 'vague plan' as much as we can have one in open source. Here is what I propose: 1. we decide that 3.6 (no reason to call it 3.9?) should be the last minor release on 3.6, lets try to make a nice 3.6,... we can then issue bugfixes like 3.6.1, 3.6.2, ... 2. copy trunk to branch_4x and call it our 'stable branch' (even though it isn't, not yet). 3. trunk is now 5.x and open for scary changes like trunk is today. 4. eventually, when its right, we issue alpha or beta or real release off branch_4x for 4.0 I think this has some good practical implications: 1. people can still add new scary cool fun stuff to trunk as always. 2. new scary stuff isnt being added to branch_4x constantly destabilizing it (but certainly features that are safe, just like branch_3x today!) 3. since initially branch_4x and trunk are close, we essentially double our jenkins coverage (currently we spend half of it on 3.x, but this isn't helping stabilize 4.x code) > A SimpleText impl for docvalues are certainly nice to > have but not a blocker from my perspective. I already worked on it and > it will make it into 4.0 but we need to mark those issues that are > real blockers. > I actually think we should have a SimpleText impl for everything, here's why: 1. we need multiple implementations to flush out any assumptions in the abstract APIs. 2. we need to ensure multiple impls actually work for backwards compatibility to actually work in the future. 3. we need to fix tests to not have things like hard-coded assumptions about filenames so the tests are actually useful. Sorry for the example by the way, i didnt mean to pick on docvalues. Probably even worse is the fact I left a lot of codec impls really bundled together inside 4.x impls without splitting out the 3.x stuff. Until we do this, how do we know back compat will really work with codecs? -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
