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

On Mon, May 26, 2008 at 7:41 PM, Michael Peddemors
<[email protected]> wrote:
> On Monday 26 May 2008 18:34, Paul Lesniewski wrote:
>> On Mon, May 26, 2008 at 6:28 PM, Michael Peddemors
>>
>> <[email protected]> wrote:
>> > Sorry, I misunderstood then .. I guess I didn't set the conditions, a lot
>> > of recent discussion was about others who have 'branched' SM, and our
>> > branch work is on the 1.4.xx Branch..  the idea is by looking at our
>> > requirements of our branch, the issues can be considered in the future..
>> >
>> > If details on our branches from the 1.4.xx tree are helpful, I will
>> > refrain from posting the differences..
>>
>> We're more than happy to see your requirements and the things you had
>> to change.  1.4.x is our official stable branch, though, so we try to
>> keep changes to a minimum there.  Input against 1.4.x is often helpful
>> in 1.5.x too.  If you have things that can be considered buggy in
>> 1.4.x, we'll definitely want to fix those things.
>
> Sorry, I saw a lot of changes in the 1.4.xx branch to date, some of them
> seemed to be enhancements.  Not trying to be argumentative, but what
> is 'minor' in the committers eys..

It's a case-by-case thing.  From time to time, given how long 1.5 is
from a stable release, we backport enhancements and add some small
features to 1.4, especially if the changes have a low impact on the
code.

> no use asking for changes like adding css
> style and div tags

Yes, those kinds of things are not likely to make it into 1.4.

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

> Thought it would be a 'nice thing' if SM could ship stable by default with the
> ability to look like the version that our stable gets shipped..
>
> Just let me know what can be expected to be looked at or what you feel is
> suitable to pass on to the list, so I know that I am not wasting my evenings.
>
> I understand that not always what I think is helpful, is what others want to
> see, and read..

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.

> Just want to try to be open about we do, and not that I have many free cycles
> at all, but if I or the company can contribute, we like to where we can.

Thanks,
Paul

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