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)
_______________________________________________
Phpgroupware-developers mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/phpgroupware-developers