[Koha-devel] [Koha-patches] [PATCH] Bug 2176: adding SMS::Send to list of dependencies

[MJ Ray]

"Joe Atzberger" <ohiocore at gmail.com> wrote:
> On Mon, Jun 23, 2008 at 5:49 PM, MJ Ray <mjr at phonecoop.coop> wrote:
[ Ever-increasing dependencies ]
> > Maybe not inherently wrong, but it is poor marketing, isn't it?
>
> Not at all.  I never drive 100MPH or accelerate 0 to 60 in the shortest
> possible time, but it is not "bad marketing" for Ford to have 100MPH on the
> speedometer, and to publish their performance times.  Nobody will be scared
> off by dependencies that install themselves cleanly in the background
> without their intervention.

There we disagree a bit.  Ford takes a kicking in the UK if they
try to make a feature out of their top speed.  It's also rather
difficult to define "install themselves cleanly" well: are our use
cases still the same as they used to be?

[...]
> This sounds like agreement.  I rewrote the LDAP handling for Koha and it's
> dependencies are already optional.  The feedback from earlier versions of
> the installer that indicated that was pretty poor though.  Something like:
> You should run: perl -MCPAN -e 'install "If you want to authentify to LDAP,
> install Net::LDAP on your system.";'

Not to get into too much detail on an old, now-fixed bug: please
everyone test releases on a naked system if possible!

[...]
> Then besides our method of accounting for optional deps, the other question
> is how to categorize deps as friendly-enough-to-be-included or
> problematic-enough-to-be-optional.  We should have one or more of the
> following:
>
>    1. Explicit criteria, so the developer knows which path to take.  For
>    example, that PurePerl modules are OK.  This helps the developer know
>    *before* the dep is added.
>    2. Specific systems (OS's) that we are targeting, such that compatibility
>    on all of them would be sufficient.  I want to acknowledge the tendency of
>    this topic to drift off into OS wars and advise that we be strictly
>    pragmatic.
>    3. A vetting process for proposed deps, ideally including buildbots or
>    other automated checks.  The automated steps help the developers catch
>    problems *after* the dep is added (to test code, at least).

4. No new required dependencies during the release engineering phase
except to clear a blocker or critical bug.

Regards,
-- 
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel