lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uri Boness (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Date Sat, 02 Jan 2010 21:11:54 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795920#action_12795920
] 

Uri Boness commented on SOLR-1602:
----------------------------------

I think it is very important to understand all sides here. 

I fully and totally support Chris's attempts to clean up the code base which rightfully involves
moving classes from one package to another. I think in some cases such cleanups need to come
at the cost of user comfort as eventually they, as users, also gain from it as the system
as a whole becomes more robust, extensible and maintainable. The good thing is that besides
the deprecation issue I believe there is a consensus about the required changes. So thumbs
up Chris!!!

To deprecate or not to deprecate, that is the question. In a widely used library/framework/system
with a large (or fast growing) install/user base such as the Solr community, the common practice
is *not* to just break BWC without giving the users some grace period in which they can adjust
their deployments to the new changes. Sometimes, it's absolutely necessary (such in the cases
of bug fixes) but when it's not, in general it can create the opposite effect than you want
with the community - instead having the community appreciate your improvements and see Solr
as an "improving with time" product, they turn and see Solr as an inconsistent and sometime
even unreliable product. So from my experience with delivering goods for the users, especially
in the open source world (and I do have quite a bit of experience in that respect with the
Spring Framework) you always need to strive to 100% BWC in theory and ~95% BWC in practice
(never less than 90% though). If you stick to that, I believe changes will be widely accepted
as improvements rather than harassments. 

But there's a catch here!!!! In order to stick to these numbers, you have to adhere to two
important conditions:

1. You need to have a rather solid architecture and code base to start with. If you don't,
then naturally in the beginning you can expect many more extreme/major changes which lead
to quite a few BWC breaks (it will gradually be reduced as the architecture/codebase improves).
Whether Solr answers this condition is open for debate... there are a lot of solid parts in
Solr and quite a few parts where a complete rewrite is appropriate.

2. You need to have a steady and short release cycles. This is one thing that Solr lacks...
big time. In a 1 year release cycle, deprecating code means that for the next year (in some
cases two years), the code base will be messy with deprecated classes all over the place.
In that respect, I can definitely understand Chris's objection for deprecation as the cleanup
tasks that he's implementing may end up creating more mess (at least for a long while) than
you had before the cleanup all together. I believe that moving to shorter release cycles (including
bug-fix releases) will greatly help promoting deprecation in general.

(NOTE: just a small note about the first condition. One thing to take into account is that
*every* piece of software reaches a point in time where it needs to be completely re-written
or at least go through a *major* refactoring/re-architecturing phase. This can be caused by
many factors, let it be new technologies that are introduced, or simply limitations of the
architecture that were not foreseen. It's very important to understand and admit to this fact
- even from the user point of view it's acceptable. What is not acceptable, if it happens
too many times and too frequent) 

Bottom line, it's always a conflict between the user point of view and the developer point
of view. And there needs to be a balance and understanding of both sides. Each side needs
to understand and give in to some extend to create this balance. But to make it happen, the
culture, environment and well defined policies need to be in place. Arguing endlessly who's
right here will never bring to a good outcome, simply because both sides are right and wrong
at the same time, if you treat it as a black or white issue you'll end up loosing something
- either the user trust or a better software. How about creating a proper release plan for
the upcoming year, say a release every two months? Chris, if you have such a release schedule,
will you feel more comfortable with deprecation?

> Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters
in there
> ---------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-1602
>                 URL: https://issues.apache.org/jira/browse/SOLR-1602
>             Project: Solr
>          Issue Type: Improvement
>          Components: Response Writers
>    Affects Versions: 1.2, 1.3, 1.4
>         Environment: independent of environment (code structure)
>            Reporter: Chris A. Mattmann
>            Assignee: Noble Paul
>             Fix For: 1.5
>
>         Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt,
upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located
in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot
of them are misplaced. There should be a first-class o.a.solr.response package, and the response
related classes should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message