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

[Ryan Higgins]

I'd like to see a warning page come up when updatedatabase runs that
lists any new deps added.  This would, of course, blur the meaning of
kohaversion's db revision string if an added dep requires incrementing
kohaversion
to trigger updatedatabase, but it would be helpful for an admin who wants
to run from git to get an appropriate warning.

Ryan

--

On Thu, Jun 26, 2008 at 9:30 AM, MJ Ray <mjr at phonecoop.coop> wrote:

> "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
>



-- 
Ryan Higgins

LibLime * Open-Source Solutions for Libraries
Featuring KohaZOOM ILS
888-564-2457 x704
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20080626/39b571a6/attachment-0002.htm>
-------------- next part --------------
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel