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

[/Angles/ Puglisi]

Miles Lott (address@hidden) wrote*:
>My vote is no.

Email in .14 branch is quite buggy. I fixed every bug I could remember and/or 
was
told about. For example:

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.

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.

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

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

Email filters IS A NEW FEATURE. Well, at least 1/2 of it is. Multiple accounts 
were
coded to synergize with filters, so the full power of filters could be brought 
to
bear. The concept of the "email account" and "folder" bound to a message, was
shattered some months ago, thus allowing the filters to automatically move mail 
not
just between folders, but between different accounts on different machines. 
What IS
A NEW FEATURE is the ability to search thru the To, From, CC, BCC, Subject, and
Received headers for the existance, or lack of, certain strings. But wait, 
grabbing
and unfolding headers has been in the libraries already. The "stristr" function 
is
not new. I guess what is new is the logic of acting on a match, i.e. moving the
message based on "AND"s and "OR"s. Yes, that is a NEW FEATURE. Please advise if 
I
should disable this feature when, and if, the other bug fixes are merged, 
pending
your approval.

I honestly can not remember anything else. If you are aware of new feature I 
forgot
about, please let me know. I have, in fact, to fix 2 bugs before I could be in a
position to merge anyway. Bug #1 is I forgot to pass user submitted strings in 
the
filters UI through the "database defanging" code that has existed since before 
.12,
bug number #2 is I did not lang the "report" strings that you get after a 
filter has
run.

>Miles Lott (address@hidden) wrote*:
>My vote is no.

Well I see you prefer the former, Moderator: ignore the preceeding paragraphs.

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.

After I fix those bugs I am at your mercy.

>Miles Lott (address@hidden) wrote*:
>My vote is no.

Of course, for myself and where I work, we already use the fixed code, and I
personally advise anyone who desires a more stable email app to do so. However, 
the
decision the include the above mentioned NEW FEATURE(S) and bug fixes in the 
release
is entirely a matter for the leadership team. I am not emotionally involved if 
the
released email product is inferior and more buggy than "devel" code, because 
this
does not involve me nor my co-workers anyway, and because I would not have made 
such
a decision had I had any input.

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.

>Miles Lott (address@hidden) wrote*:
>My vote is no.

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.

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.

>Miles Lott (address@hidden) wrote*:
>My vote is no.

However, I have publicly dis-avowed that methodology because (1) it violate the
chain of command in a large project which is degrative to the project and to the
principles of people working together, and (2) I no longer have the energy to 
fix
things people do not want me to fix, should that be their decision.

I hate politics and consider this stuff, albeit extremely important, to be a 
"side
show" for me because all I care about is coding the best email app that is 
humanly
possible. Time spent on other things, even on this email request to merge bug 
fixes,
is a necessary part of this project becoming larger, so I guess this a one of 
those
"problems" you want to have, but I'd rather be writing code.

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. Perhaps an apt example is the proportional representitive deomcracy. If a
software project were to follow such an example, perhaps lines of code 
committed to
CVS could be the "proportional" element, forming a body who in turn votes on the
executive. But I digress...

As a student of government, I caution you against excessive bureaucracy (i.e. 
lack
of the executive element). At least Dan could make and implement a decision, 
this is
the nature of an executive. I'm speaking here about leadership structure, in the
abstract, and I noticed a lack of an executive element in the leadership 
structure
you described in your email.

This CEO type of person exists in businesses across the spectrum. I mention this
because I do not wish our growing project to languish because of a leadership
structure that *may not* have been well planned against historical norms. 
Especially
in the case of small, fast growing companies, a strong and visionary executive 
often
pushes the company through the early period before the business reaches 
maturity,
which happens because of the sucess of said executive. There are too many 
examples
of this for me to site. My $0.02 is simple: be aware of history, be aware of 
common
mistakes other have made before. We're going to get big, as a project, but we 
also
must be nimble.

Miles Lott (address@hidden) wrote*:
>
>My vote is no.  Only bug fixes to what exists in .14 branch
>should be committed.  Now if we can get everyone else on board...
>
>/Angles/ Puglisi wrote:
>> After that, IS IT OK TO MERGE and have it tested. AFIAK everything is stable 
>> but
>> the filtering just will need some testing.
>
>--
>
>Miles Lott - phpGroupWare
>http://www.phpgroupware.org
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>