Re: Merging Changes from 1.4.15 and MagicMail's version..

> I think this it what leads to branches,
> and can lend itself to more issues, like everyone was complaining about
> Nutsmail not giving back.  If they feel that it wouldn't be appreciated
> anyways..people get real silent real fast..

Sure, I understand, but when we say "stable", we try to make that have
some meaning.  Uprooting the GUI code can be a little messy.  Even if
not, I think it is best to focus our limited resources on the more
important and fundamental changes in 1.5 in that regard.

>> > into the branch unless it is going to be acceptable. What
>> > level of changes will go into the 1.4.xx branch? The reason, I am working
>> > at night here was to try to give a little back while doing an audit of
>> > changes that need/should be ported over to our the packaged versions we
>> > ship.
>>
>> It's very nice of you to do that.  I think the criteria that makes
>> sense in this case would be that you shouldn't worry about GUI-related
>> changes, but those that involve functionality or bugs can be judged on
>> a case-by-case basis, and will also be useful for integration into our
>> next generation in 1.5.
>
> GUI is the main area we work on..  and frankly the next gen branch from what
> our team have seen have not made it simpler, and didn't impress the others
> that I had testing it here..

Sharing your opinions and impressions with us could be helpful.

>  And by the time 'next gen' gets to stable,
> which is what we need to run for our clients, when this comes out for us,
> market pressures may already have pushed us in other directions, eg Flash, or
> RoundCube based..

1.5 when finished should be able to do anything RoundCube can, along
with all the other things that you've come to know and love about SM.

>. As quick as SM is, and effective in high volume
> environments, we would have challenges trying to get 1.5.
>
> With 1.4 we can have our graphics people bang out hot looking SM
> customizations in only a couple of hours..

A full skin/set of template files IS a lot more work than making the
menu bar links into image links, but that's the price of progress.
;-)

> And by the way, as a business I do have to point out we already get enough
> pressures from tech's who perceive SM as 'outdated', and when they report
> that to our potential customers, the GUI warm fuzzies are important.  Even as
> far as we have pushed the stable SM, it has cost us in business already
> against other WebMail implementations.

That's exactly why 1.5 is fully skinnable.  You just supported my
arguments above.

>> I'm sure others might appreciate seeing even your GUI related changes
>> if they are working on sprucing up their 1.4 installation, but our
>> core product GUI efforts are focused on the 1.5 stream.
>
> Okay, are they expected to run forked code if they like the changes I post?

They can do whatever they want with the code.  That's what FOSS is all about.

> See, that is the dilemna, don't need to create flame wars on the list, that
> sure won't help the SM movement, and I sure don't want to support a 'public
> branch', I would rather have it under the one umbrella.

Thanks for your input.

> PS, the 'filter' plugin you use should have a warning about the use of
> SpamHaus, because of SpamHaus's policy now of blocking people of certain
> sizes from using it as a sales method

I'm not familiar with this problem.  You might provide links if you
have any that detail the issue.

>, it can cause problems where the ISP's
> get blocked.  I didn't go deep into the code in the filter plugin, but have
> seen in the wild where we get emergency calls from people using SA etc, and
> the service effectively getting hung up trying to do lookups against the
> Spamhaus list all of a sudden, and the person doesn't know why..

This should probably be in a thread of its own....

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel