[Koha-devel] updatedatabase (bug 7167)

[Paul Poulain]

Le 24/11/2011 17:02, Chris Nighswonger a écrit :
> On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain
> IMHO customers who want features before master inclusion is really a
> vendor issue, not a community issue.
Chris_n, I disagree (strongly) with you here: according to me, anyone
issue is important. We should not discard anything just because it's "a
vendor issue". Well, at least when the ppl who had a problem comes with
a patch!
For example, Eliott' thread started a few hours ago is interesting:
frankly, having pain merging the hourly loans patch is "a library issue,
not a community ones". Well, in fact, I don't think so. Solving problems
and making ppl happy is important. That's how we will attract more
developers.
6 months ago, i've started a thread that explain this better than I do:
http://www.codesimplicity.com/post/open-source-community-simplified/
Just the paragraphs headers:
"
Retaining Contributors
* Respond to contributions immediately.
* Be extremely kind and visibly appreciative.
* Encourage a total absence of personal negativity.
"

In this specific case, bug 7167 is trying to solve a problem that has
been discussed during hackfest, and ppl agree it is (a problem). So it's
not a "vendor issue" only.
The patch will:
* ease developer work (ie: merge conflict removed)
* ease RM work (ie: no number to assign when pushing). It also mean
lower the risk of doing a mistake
* simplify the code a little bit (ie: not checking on everypage that
there is something to do, it's made just on mainpage.pl)
* give more feedback (ie: DB changes are stored in the database. If
there is a problem, you'll be able to know what happened. As a vendor,
it's important: we can "prove" that a patch has been applied -or not-
even 2 months after the update. That's a *big* improvement when you have
100+ Koha setups to manage !)

I can also add "having a feature before official inclusion" is, in fact
very good for the community !
I think there are some (few ?) libraries that could be happy to:
* test a patch on their test server
* if it works, apply it to production server
* if things goes OK, "sign-off" the patch on bugzilla
=> patch is signed-off, it's good for the community.

> Yes, we want to make changes that
> will make life easier on vendors (and therefore their customers),
> *but* not at the expense of rushing and possibly introducing a
> potentially buggy, not-throughly-tested "enhancement."

I don't understand why you say that. The patch is submitted, i've tested
it heavily, I don't plan to push is without respecting the workflow, so
there is no more risks than for any other patch !
What I agree with is that I won't let this bug be lost in the wild, as
it's an important structural change I want to do first before pushing
any important new feature. For version consistency, it's better.

So, my proposal: stop feeding a possible troll, and go test my patch ;-)

HTH
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08