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

[Mark A Peters]

Let me open this email by saying that I don't respond to this type of
dribble very often, so excuse me up front for offending people.


On Sat, 2 Feb 2002, [iso-8859-1] /Angles/ Puglisi wrote:

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

I think that one important thing to state here is that there was a call
for feature freeze.

FEATURE FREEZE      
Submitted by milosch 12/23/2001 - 06:12:57 pm 
OK, we are a day late. But, the feature freeze for 0.9.14 is now in effect. 
Now it is time to concentrate on cleaning up the current code in preparation
for a release candidate. Look for another announcement here when that is ready.

feature freeze for phpGroupWare-0.9.14 release      
Submitted by ceb 12/20/2001 - 08:12:43 pm 
Within the next 2 days a feature freeze to the current development code will
be announced. At that time a branch will be created to begin testing and
fixing prior to the next release. An official test procedure will be in place
within the next two weeks. We are looking for testers to check the release
candidate.  Please submit bugs and patches to the sourceforge project for 
phpGroupWare. If you do not have an account, include your email address if 
possible. The phpGroupWare-0.9.14 release hopefully will be out in 
january 2002.

Now, things may not have gone as scheduled in these announcements, due to
the moving of CVS from SourceForge => Savannah.  But the fact remains that
a call for feature freeze was announced.

In all of my time as a software developer (in excess of 10 years, almost 
18 years exclusively in some capacity in the IT business), I have
taken this to mean that no more FEATURES were to be added for this
proposed cut.  This means establishing a baseline to be considered for
release; only bug fixes to existing problems can be
addressed.  Not introducing new processes/procedures to fix existing
problems.

This is something that has to be done so we can establish a good
BASELINE to introduce new features for the next round developement.  When
I go to introduce a new feature, I really don't want to spend time wondering
if the new code is introducing the problem or if it was something that was
blatantly broken in the last release.  I should be able to tell almost
immediately it's something newly introduced.

I believe this is what's called the waterfall development model.

I believe sufficient time was given to everyone that a code freeze was
being implemented.  I didn't build the .tar.gz .bz2 .zip files for almost
3 weeks.  For myself, I had self imposed a freeze on most code I was
working on about 3 weeks prior, so I can work out any loose/obscure 
bugs floating around.  With that, I WOULD have liked to do some more stuff
with XML-RPC and the holiday management system, but did not.

Why should we allow you to introduce the amount of features you are asking
to implement?

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

That's the nature of software developement.  Bugs/problem reports will
always be with us.  I have never met a single developer who can write good
clean code in their first 100 times.  (Maybe exluding Microsoft..
Oooppss.. BG just mandated M$ address software security issues (not really
a bug)).

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

Oh.  I have never heard of a software package being developed by a
democratic society.  There has to be a clear and concise direction given by 
a single entity, not by a vote of the general public. It just happens that 
phpGroupWare does have a governing body consisting of Dan (Seek3r), 
Joe (Jengo), Miles (Milosch), ceb (Bettina), and myself.  That's not to say 
we can't ask the general populace in what direction they would like to see 
certain pieces turn into.  Just give me an example of a piece of software 
that has been developed where no leadership (Autocracy) existed.

I'm sorry to say Angles, but since July 2000, I've been coding and helping
with the general guidance of phpGW.  That's nearly 2 years of nights 
and weekends I've put into this project, after a full day of working my
normal day job (US Military).  
> 
> 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.

Well, you are a student of government, I am the government.
(government of the people, for the people and by the people)

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

"languish because of a leadership structure that *may not* have been well 
planned against historical norms"?  If you are truly a student of
government, you would already understand.  The fore fathers of the US
Constitution was more wiser than you could imagine.  They had one thought
in their mind when building/designing our government.  They knew that they
would'nt build it properly the first time.  They built into the
consititution the method of how things could be changed.  They knew that
what they built today, would not be appropriate for tomorrow.  The same
thing here.  We seen what we did have as far as a governing body of the
project was not able to grow needs of today or the future, so we adapted
the structure to something that could work for now and still allow us to
change it later.

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

I agree with Milosch on this.  Only bug fixes to what exists in the .14
branch.  Again, we are trying to stabilize what we are looking to release
to the general prublic, not cause more last minute headaches.

Thanks,
Mark A Peters (Skeeter)