On Sun, Jan 8, 2012 at 8:05 PM, Robert Muir <[email protected]> wrote: > 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
ah ok phew :) > > 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, ... +1 to this. lets get 4.0 rolling... I don't think we need to jump to 3.9 > 2. copy trunk to branch_4x and call it our 'stable branch' (even > though it isn't, not yet). +1 I think we should actually do that soonish, is there anything which keeps us from branching IMO today is as good as tomorrow. What is the status of solr-cloud? I mean is this going to be ready within a reasonable amount of time? That feature by itself could justify a 4.1 release immediately I'd say. > 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 agreed, I think we should never again release even a alpha off trunk. On trunk folks should be allowed to go crazy and do scary changes... on the stable / stabelizing branches we should be more conservative. > > 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]
