[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss] Refactoring KahaDBStore class

gtully wrote
> Jamie,
> you are missing my point. it is a tradeoff plain and simple. easier to
> maintain for who? It has been carefully maintained for more than 7
> years.

I am a bit confused and surprised.  Its been maintained for 7 years by a
small select few of what has become stovepipe app development. 
MessageDatabase alone has over 4000 lines of convoluted and very hard to
follow Java code.  Jamie appears to have done a heck of a service to the
community by simply cleaning some of KahaDB up and making things more
readable. You asked "Easy to maintain for who"?  The entire community.  Did
you look at his changes?  You may find them to be a gain for you.  Your
comment above evinces ownership of a codebase which is contrary to making
things right for the community.  This disenfranchises further and future
contributions to the codebase.

As it stands, you are certainly the expert when it comes to KahaDB.  This is
a good opportunity to make this more maintainable so that you are not the
only go-to person when it comes to this code area.  If I was in your shoes,
I would welcome this change because it relieves you of having to be a single
point for all these changes to go through.  When I see comments of "I am too
busy, I can get to it next week" or other committers saying "Gary is the
expert, I want his eyes on it before committing it", this becomes very

gtully wrote
> Do refactoring at the beginning of a release cycle, not at the end.
> diffs between 5.15.x and 5.16 will be meaningless otherwise.
> push out 5.16.0, which has loads of incremental (non refactored) small
> changes. Then refactor away on master for 5.17.0 and make it better in
> any way that works for the future and for you. 

This *is* the beginning of a release cycle.  5.16.0 is a perfect place and
time to do this.  5.15.X train is about to end and it makes much more sense
from a maintainability perspective to do this now.  That is to your point
about having to backport.  Doing it now removes that as a pain point.  I
really think that a reasonable review of what Jamie has done from you could
be beneficial as you may be delightfully surprised at what was done.

I believe Jamie and Arthur have put a lot of thought, time, and sweat into
starting this effort, and it was done as a benefit to the community, not
personally.  I believe you have a wealth of experience in this area and it
would be great to have you support the effort so it makes it even easier on
you for multiple reasons.

Waiting for 5.17.0 for something that really is non-invasive is asking quite
a lot.  If 5.17.0 is to be released in the next few weeks, then sure, lets
do that.  But we both know 5.17.0 (if it follows history) likely won't be
released until 2020.

This is not a major refactor.  Its just code clean up and making the code
more modular.  Your input would really be appreciated.


Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html