[Koha-bugs] [Bug 7167] updatedatabase improvements

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167

--- Comment #45 from Paul Poulain <paul.poulain at biblibre.com> 2012-01-06 14:38:55 UTC ---
(In reply to comment #41)
> However, I'm not sure that the correct "mechanism" here is a "Failed QA." In my
> opinion QA is pretty objective. ie. does the code do precisely what it claims
> to do. None of the points listed indicate that the code submitted does not
> behave as advertised. They are all good points, but fall more into the pail of
> the "is this the best way to do it" discussion. Maybe I'm wrong in that
> thought. If so, feel free to correct me.

Thanks chris_n !
That was my 1st reaction, but I didn't wanted to write it immediatly to avoid
being suspected to refuse the discussion.
I agree that QA should be objective.
OTOH, Ian & me had a long discussion about this improvement at KohaCon, and I
consider his thoughts more a follow-up of this discussion than a QA.

Agreed we should have a "discussion" status !

Now answering Ian points:
(In reply to comment #36)
> 1. it seems that, what we initially discussed for this is not what we got, as
> far as code.  There was some BibLibre work that was similar, so that was used
> instead of implementing the idea from Mumbaï in it's entirety.
You're right here. That does not mean it's not a good piece of code.

> 2. making changes to the way database updates are handled effects all versions
> of Koha.  This process needs to remain stable at all costs.  Thus any change
> must be most thoroughly tested
you're right, and we (jonathan & me) have spent a *lot* of time testing this
one.
I also must point that this patch is not exclusive of the actual DBrev system :
both are still working. It means that patches already submitted with
updatedatabase can still be tested/pushed

> 3. there is a rush order on this, which makes me uncomfortable.  Yes, it would
> be nice to start the release cycle with a new method, but we're already well
> along the development timeframe for 3.8, and I think changing midstream is
> going to introduce more complications than it's worth

The rush level has been lowered by the clarification made on DBrevs, and the
mails i've sent today (as well as the update of master i also made today)

But:
* the 3.6 updatedatabase has a limit for testing patches as well as a risk for
backporting DBrevs to 3.4, addressed by this patch
* this bug is an absolute necessity for the sandbox system i'm working on.
Without it, it won't work (because updatedatabase have a XXX, so no patch with
a DBrev will apply)

> 4. Frankly, I don't feel the need to rush this.  This project offers no
> particular benefits to the end user.  It's only really helpful to testers and
> developers.  I'm all for making it easier to test patches, but not at the risk
> of breaking upgrades for any set of Koha users.  I'd rather see this
> implemented in the next release cycle, so we have adequate time to plan and
> test.

Does it mean your only fear is that it could break something ? and you haven't
tested or found anything broken ?
Yes, it's a core change, but we should not fear doing core change just because
it's in the core !

> 5. Moving database updates into the atomic update directory is a good thing,
> for sure, but assigning them numbers makes them inherently linear, which we're
> trying to avoid.
yes and no : the numbering ensure we have an order, but it's not linear because
we can have holes in the numbering.

> 6. I disagree with removing the Version check on every page.  We're in an
> asynchronous web environment; the system could be upgraded while folks are
> mid-stream in their work (not a recommended practice, but one that we need to
> acknowledge as possible).  If a database change significantly affects the
> structure of the area in which people are working, the information they are
> submitting/querying could become corrupted, or not work at all.  The code and
> the database must be kept synchronous, at all times, with no need for manual
> action.
we disagree here : upgrading a software is not something you do without knowing
you're doing it. There is a procedure, and the check has been reintroduced on
every mainpage, It's enough !
Note that, if you continue to argue it must be done, then i've a counter
proposal:
at the end of each upgrade, run truncate session, thus the user will be
disconnected, and, on connection, he will be sent to database update !

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.