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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
