[imp] 6.1.0-git

Sat May 18 23:20:49 UTC 2013

On 18 May 2013 03:54, Andy Dorman <adorman at ironicdesign.com> wrote:
> On 05/17/2013 04:07 PM, Simon B wrote:
>>
>> On 17 May 2013 23:03, "Simon B"<simon.buongiorno at gmail.com>  wrote:
>>>
>>>
>>>
>>> On 17 May 2013 22:51, "Michael M Slusarz"<slusarz at horde.org>  wrote:
>>>>
>>>>
>>>> Quoting Simon B<simon.buongiorno at gmail.com>:
>>>>
>>>>> On 16 May 2013 19:38, Michael M Slusarz<slusarz at horde.org>  wrote:
>>>>>>
>>>>>>
>>>>>> Quoting Simon Brereton<simon.buongiorno at gmail.com>:
>>>>>>
>>>>>>> On 10 April 2013 12:02, Simon Brereton<simon.buongiorno at gmail.com>
>>
>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10 April 2013 11:39, Nuno Lopes<nuno.lopes at portugalmail.pt>
>>
>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Simon,
>>>>>>>>>       from what I understand the funcionality hasn't gone away, it
>>
>> has
>>>>>>>>>
>>>>>>>>> been
>>>>>>>>> moved to another configuration. You can read that in the upgrading
>>>>>>>>> documentation:
>>>>>>>>>
>>>>>>>>> The following spam-reporting options have been removed and can now
>>
>> be
>>>>>>>>>
>>>>>>>>> configured per-backend in ``config/backends.local.php``::
>>>>>>>>>
>>>>>>>>>     $conf['notspam']['email']
>>>>>>>>>     $conf['notspam']['email_format']  ...
>>>>>>>>> https://github.com/horde/horde/blob/master/imp/docs/UPGRADING hope
>>>>>>>>> this
>>>>>>>>> helps, -- Nuno Lopes
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> So I see.  I'd still feel better knowing the rationale for these
>>
>> changes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Because it made zero sense to set a one-size-fits-all spam reporting
>>>>>> solution in the configuration file.  What happens if you have two
>>
>> servers
>>>>>>
>>>>>> listed in backends.php, your local IMAP server and Gmail?  I'm about
>>
>> 102%
>>>>>>
>>>>>> sure that you do not want the same spam reporting configuration for
>>
>> both of
>>>>>>
>>>>>> these servers.
>>>>>>
>>>>>>>> Not that my userbase uses this feature, but I can this will cause
>>
>> some
>>>>>>>>
>>>>>>>> confusion too..
>>>>>>>>
>>>>>>>> The following options have been removed::
>>>>>>>>
>>>>>>>>     $conf['compose']['link_all_attachments']
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So, I've added these configurations items to
>>>>>>> imp/config/backends.local.php and still I have no report as spam
>>>>>>> button in my mail interface anymore.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> And you added them in the correct format, as described in
>>>>>> config/backends.php?  You can't just copy/paste the old lines from
>>
>> conf.php,
>>>>>>
>>>>>> if that's what you did.
>>>>>
>>>>>
>>>>>
>>>>> Interesting - the old way was of course much easier to configure :)
>>>>
>>>>
>>>>
>>>> I would disagree.  Previously, you may have had to configure in BOTH
>>
>> conf.php and in a hook, depending on the backend.  That is a confusing
>> configuration design.  Now all configuration takes place in a single
>> location.
>>>>
>>>>
>>>> Just because it is less familiar doesn't mean it is not easy.
>>>>
>>>>
>>>>> Innocent reporting is a little trickier.  How does one move it back to
>>>>> the Inbox?  From the docs, I have:
>>>>
>>>>
>>>>
>>>> Post-spam actions are a user-defined activity, so this is configured in
>>
>> the preferences ('move_innocent_after_report').
>>>>
>>>>
>>>>
>>>>>>> How is it possible to go back to a version that has it?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> If you already upgraded to IMP 6.1, hopefully you created a backup of
>>
>> IMP
>>>>>>
>>>>>> 6.0.x you can revert to.
>>>>>
>>>>>
>>>>>
>>>>> How does that work if you install via pear?
>>>>
>>>>
>>>>
>>>> You could have cloned your installation.  Or installed to a different
>>
>> PEAR directory.
>>
>> Oh, and I had a separate pear install - despite the install docs warning
>> that it's not recommended even if you do provide instructions for it - for
>> stage, and upgrading was a nightmare, which is why I moved to git.
>>
>> Simon
>>
>>>> These days, it really isn't the (potentially time-consuming)
>>
>> responsibility of a software project anymore to support these kind of
>> "multiple-setups on a single machine", at least software projects that
>> don't have vast resources.  VMs are so ubiquitous, cheap, and easy to
>> setup
>> and they accomplish precisely this.
>>>
>>>
>>> Maybe not, but a downgrade path would be nice.  If, I discover a bug, in
>>
>> apache or OpenOffice, I simple purge and reinstall (and by and large) my
>> settings and preferences remain intact.
>>>
>>>
>>> You're saying, I have to create a virtual machine every time a new
>>
>> version comes out (sorry, but I can only afford a 2gb/500gb/€50pm box, as
>> much as I would love a 32gb/1tb box).  And how does the database work?
>>>
>>>
>>> If there's a schema change from 6.0 to 6.1 (which there was), how do I
>>
>> move the delta data back to 6.0?  To my knowledge, there's no button in
>> the
>> interface to downgrade a db schema...
>>>
>>>
>>> Simon
>
>
> Simon, give it a rest.  If you need a button to back out a release then you
> are in the wrong profession.

Hi Andy,

I seem to have missed the professional requirements for participating
in an open source project - perhaps you could point me to them?

Whilst you are doing so perhaps you'll also have the time to re-read
my email.  You will then perhaps notice I am not asking for a button
to down-grade.  I was simply making a point that the solution that was
proposed to me doesn't in fact make sense since it it will introduce
more problems than it solves.  Not being sure of what your profession
is, and frankly not caring or believing it worthy of influence in this
discussion I wouldn't dream of telling you you're in the wrong one,
but it seems to me that which profession it is doesn't rely too much
on comprehension.  More power to you my son.

> To avoid surprises like you have apparently received here is what you should
> do in the future.
>
> 1. Pay $20/mo for a VM slice at Linode or your favorite VM provider
> 2. Configure an "alpha/beta" test server on this slice exactly like your
> production server(s).
> 3. Point an MX for test.mydomain.com at it with email accounts for all your
> staff (and sign up for a bunch of newsletters with those test addresses to
> generate lots of traffic)
> 4. Import and test new releases on your alpha/beta test server BEFORE
> pushing it to production.

Sure, I've done this - thanks for the advice.  Where do I send the
invoice for the $20 every month?

> Yeah, the little VM slice will be underpowered ($20/mo at Linode gets you
> 1GB RAM), but that is what you want in a test machine...

> And if there is a problem with a release, no big deal...all that is affected
> will be your test site...just figure out the new config or send a suggested
> patch or report how to reproduce a bug reliably and let the developers fix
> it for you.  And if a project takes a direction you don't like, with Open
> Source you always have the option of using a good VCS like Git to develop
> and maintain your own local changes and just merge in upstream changes in
> all other areas.

What you've failed to comprehend - stated as it was, although it's not
relevant to my point - is that the my issue IS in the test site.  My
production site is still running Horde 4 and has been doing so because
passwd was not available.  Now that passwd is available, I would love
to finally migrate production to H5 - but unfortunately the same
release that brought me passwd has robbed my users of some other core
functionality. (I must be in the wrong profession after all because I
care about continuity, care calls and user satisfaction).

I say robbed, but technically it's misplaced since I'm assure the
functionality is there (and I believe it) - but despite following
Michael's advice I am not able to locate/restore it.  Thanks again for
you input - although I feel if you can't be constructive you should
give it a rest.

Cheers!

Simon