Re: Commented: (LUCENE-1678) Deprecate Analyzer.tokenStream

[Mark Miller <ma...@gmail.com>]

Earwin Burrfoot (JIRA) wrote:
> -----------------------------------------
>
> bq. If there are sane/smart ways to change our back compat policy, I think you have seen that no one would object.
> It's not a matter of finding a smart way. It is a matter of sacrifice that has to be made and readiness to take the blame for decision that can be unpopular with someone.
> You go zealously for back-compat - you sacrifice readability/maintainability of your code but free users from any troubles when they want to 'simply upgrade'. You adopt more relaxed policy - you sacrifice users' time, but in return you gain cleaner codebase and new stuff can be written and used faster.
> There's no way to ride two horses at once.
>
> Some people are comfortable with current policies. Few cringe when they hear things like above. Most theoretically want to relax the rules. Nobody's ready to give up something for it.
>   
I don't agree. I think everyone would be willing to give something up. 
But some won't want to give up certain things.
> Okay, there's an escape hatch I (and someone else) mentioned on the list before. Adopting a fixed release cycle with small intervals between releases (compared to what we have now). Fixed - as in, releases are made each N months instead of when everyone feels they finished and polished up all their pet projects and there's nothing else exciting to do. That way we can keep the current policy, but deletion-through-deprecation approach will work, at last!
>   
Thats a big change. I think its a nice idea, but I don't know how 
practical it is. Most of us are basically volunteering time for this 
type of thing. Even still, with the pace of development lately (and you 
can be sure that the current pace is a *new* thing, Lucene did not 
always have this amount of activity), it might make sense. But that idea 
needs a champion, and frankly I don't have the time right now (it 
wouldn't likely be in my realm anyway). And thats probably the deal with 
most others. They have work and/or other itches that are higher priority 
than championing a big change.
> This solution is halfassed, I can already see discussions like "That was a big change, let's keep the deprecates around longer, say - for a couple of releases.", it doesn't solve good-name-thrashing problem, as you have to go through two rounds of deprecation to change semantics on something, but keep the name.
> But this is something better than what we have now, a-a-and this is something that needs commiter backing.
>
> bq. Thats a great indication to me that the issue is not simple.
> The issue is simple, the choice is not. And maintaining status quo is free.
>   
Right. Its not about anyone arguing against it. People made arguments 
and raised points from various angles - none of that biases the 
conclusion, it only strengthens it. I poke holes at things I fully 
support - it should survive the shot if it makes sense. It comes down to 
the effort involved in guiding this forward. I know the majority want to 
see something succeed. Probably the best argument is the one Mike first 
championed - we are hurting new users by saddling them with back compat. 
I think we all want a better compromise, leaning further towards out of 
the box experience than we do now.
> bq. Giving up is really not the answer though
> It is the answer. I have no moral right to hammer my ideals into heads that did tremendously more for the project, than I did. And maintaining a patch queue over Lucene trunk is not 'that' hard.
>   
Its not about hammering your ideals - that almost feels like what you 
are doing, but frankly, it doesn't help. If you even just keep prompting 
the issue as it dies away you will likely keep progress going. There is 
a solution that everyone will accept. I promise you that. Its more work 
than it looks to find that solution and guide it to fruition though. Its 
fully possible, and I'm sure it will happen eventually. Would have beat 
even money that Mike had it a few weeks ago. No dice it looks though ;)

- Mark
>
>   
>


-- 
- Mark

http://www.lucidimagination.com




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

Re: Commented: (LUCENE-1678) Deprecate Analyzer.tokenStream

[Yonik Seeley <yo...@lucidimagination.com>]

On Tue, Jun 9, 2009 at 8:23 PM, Earwin Burrfoot <ea...@gmail.com> wrote:
>> IMO, changes to interfaces should be clearly better than what existed before.
> Recent changes to DISI? Were they clearly for the better?

Recent *proposed* changes.... yes, for 3.0.
If you include the scorer changes, it's a bigger change than it
appears, and one I'm not sure I'd be comfortable with in a point
release.

-Yonik
http://www.lucidimagination.com

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

Re: Commented: (LUCENE-1678) Deprecate Analyzer.tokenStream

[Earwin Burrfoot <ea...@gmail.com>]

@Mark:
>> Okay, there's an escape hatch I (and someone else) mentioned on the list
>> before. Adopting a fixed release cycle with small intervals between releases
>> (compared to what we have now). Fixed - as in, releases are made each N
>> months instead of when everyone feels they finished and polished up all
>> their pet projects and there's nothing else exciting to do. That way we can
>> keep the current policy, but deletion-through-deprecation approach will
>> work, at last!
> Thats a big change. I think its a nice idea, but I don't know how practical
> it is. Most of us are basically volunteering time for this type of thing.
> Even still, with the pace of development lately (and you can be sure that
> the current pace is a *new* thing, Lucene did not always have this amount of
> activity), it might make sense.
You're missing the most important point. Fixed schedule means that the
only reason not to do a release is the total abscence of changes.
No matter how much or how few changes are released each time, fixed
schedule gives you predictable lifecycle for all your
deprecation/back-compat needs.

> But that idea needs a champion, and frankly
> I don't have the time right now (it wouldn't likely be in my realm anyway).
> And thats probably the deal with most others. They have work and/or other
> itches that are higher priority than championing a big change.
And here we got at one of the roots of the problem. The root that is
going to stay.

>> bq. Giving up is really not the answer though
>> It is the answer. I have no moral right to hammer my ideals into heads
>> that did tremendously more for the project, than I did. And maintaining a
>> patch queue over Lucene trunk is not 'that' hard.
> Its not about hammering your ideals - that almost feels like what you are
> doing, but frankly, it doesn't help. If you even just keep prompting the
> issue as it dies away you will likely keep progress going. There is a
> solution that everyone will accept. I promise you that. Its more work than
> it looks to find that solution and guide it to fruition though. Its fully
> possible, and I'm sure it will happen eventually. Would have beat even money
> that Mike had it a few weeks ago. No dice it looks though ;)
I consciously took a bit of an extremist stance in hope to shift the
mean. Okay, will try ditching it in favour of gently bugging people
like Grant did in the comment that spawned this discussion. :)

@Yonik:
>> You go zealously for back-compat - you sacrifice readability/maintainability of your code but free users from any troubles when they want to 'simply upgrade'. You adopt more relaxed policy - you sacrifice users' time, but in return you gain cleaner codebase and new stuff can be written and used faster.
> Not sure I agree with that - if changes become too easy you can get a
> thrashing effect... change just because someone thought it was a
> little better can lead to more chaos.
You're right.
I'm not advocating anarchy. :) But currently we are afraid to break
anything at all, and that is as far away from juste milieu as the
chaos you speak of.

> IMO, changes to interfaces should be clearly better than what existed before.
Recent changes to DISI? Were they clearly for the better?

-- 
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

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