Re: [Phpgroupware-developers] darn near email done, merge notification

[Chris Weiss]

Miles, I can't believe you responded like this!  I've been using the email app 
in
stable branch as my primary email client since 0.9.9.  The current .14 is
UNUSABLE.  I'm using .14 branch with head email right now, I don't want to 
continue
this past the release of .14.  As an involved user and past contributor to
phpGroupWare since the very first tarball release, I plead for these changes to 
be
included in .14.  If they aren't, phpgw will have an inferior email app that is
very broken.  Lets try to have a fully usable app at the release of .14, 
instead of
something that either is highly unstable or is outdated in 3 days by bug fixes 
to
the stable branch that never gets tarball released, much like the last 2 
releases
were.

New features or not, these email changes are STABLE and NEEDED for 0.9.14 to be
impresive.  There is no good reason for NOT including them.

Chris


Miles Lott (address@hidden) wrote*:
>
>/Angles/ Puglisi wrote:
>> Multiple account support .14 is broken. It is frozen at 2 accounts only. The
number
>> of extra accounts the code supports is infinate. My brain is not equiped to
>> calculate the difference between 2 and infinate, but this bug fix should be
applied.
>> That was an artificial limit imposed to expidite the HTML design of the UI, 
>> which
>> happen to coincide with the branching.
>
>feature.
>
>> The ability to preview an email in "raw" form, so you may inspect for 
>> malicious
HTML
>> scripts, does not exist in .14, this is not a lack of a feature, this is a 
>> lack
of
>> brain cells on my part as I forgot to add that HREF when I made the "view
headers"
>> link, some time ago.
>
>feature.
>
>> .14 does not transfer the "personal" part of the email address from the 
>> address
book
>> to the to,cc, or bcc boxes. I, and others who have read the FAQ, have been
manually
>> typing in the "personal" part of the email address for some 4 months now. I
finally
>> got around to fixing that a few weeks ago. I guess what is NEW there is the 
>> user
>> does not have to type in by hand the personal part. I consider this a bug 
>> fix,
it is
>> extremely abnormal that the user should type in by hand the personal part of 
>> an
>> address every time a mail is composed.
>
>It is also not necessary that they do this, so long as the email address
>is there.
>feature.
>
>> .14 does not have bcc. Almost nothing changed in the code, but that's the 
>> nature
of
>> Bcc, it gives the SMTP server another address. So the new feature there is 
>> giving
>> the SMTP server an additional RCPT TO line. Well, maybe that was a bug fix,
there's
>> no "new" code in that, just another loop through old code.
>
>feature.
>
>> Also, in the API, the class.send.inc.php is broken, I forgot to take out the
>> obsoleted "append to sent folder" code, and the line breaks do not conform to
>> RFC2822, nor to RFC822, which may seem like not a big deal but is actually 
>> quite
>> serious from a standards point of view. The "append to send folder" vestigal
code is
>> already breaking 2 apps that I have been made aware of in the chat room.
>
>used to work...  what happened?  I don't make email calls except to
>compose,
>so I don't know when it got broken.
>
>> My only hope is that the leadership team may actually spend a few minutes of
their
>> time to send and/or read an email with the app before making a decision.
>
>I did.
>
>> Whether you look at the app or not, I will, of course, respect your decision
either
>> way, because this is inherently the chain of command in large projects 
>> (which we
now
>> qualify as), and I have no desire to be a project "leader" anyway, I am a 
>> coder.
>
>Are you sure?
>
>> Last release cycle I had to ostensibly disobey "leaders" (then it was not 
>> clear
who
>> was a "leader") to get bug fixes in the release product. This did effect me
>> personally as I really got sick dealing with "bug report" emails that 
>> involved
fixed
>> issues. I should have just had an auto responder. Honestly, the irony of
extremely
>> happy customers with a bug fixed product vs. angry "leaders" chastising me 
>> for
>> fixing these bugs, was quite profound.
>
>This is great.  So you WERE doing this on purpose, pretending to not
>know.
>Try it again.
>
>The fact is that in .12:
>1) some of the bugs existed long before you showed up (why the rush
>post-branching?),
>2) still other bugs arose from the introduction of new features,
>3) MORE bugs showed up from the introduction of new features into the
>release
>branch after feature freeze.
>
>Guess which part is easy to eliminate.
>
>> Oh, I may note that in a direct democracy, leaders are voted on by the 
>> people in
>> general, while in an indirect democracy (as existed here until the last 
>> century)
>> certain leaders who were voted on then, in turn, vote on an executive leader 
>> (or
>> leadership structure). Granted, businesses are not democracies, whether 
>> direct or
>> not.
>
>I guess this is more like an oligarchy ;)
>
>> As a student of government, I caution you against excessive bureaucracy (i.e.
lack
>> of the executive element).
>
>blah blah blah - We have been in feature freeze in the .14 branch for a
>month
>now.  Yes, this may be too long to wait to release.   But it is no less
>frozen
>than before.  This is also one less month of testing in the stable
>branch
>for the email app if you perform a major commit again like last time.
>
>--
>
>Miles Lott - phpGroupWare
>http://www.phpgroupware.org
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>