phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark A Peters
Subject: Re: [Phpgroupware-developers] darn near email done, merge notification (fwd)
Date: Sun, 3 Feb 2002 16:40:21 -0600 (CST)

On Sun, 3 Feb 2002, Guillaume Courtois wrote:

> >I will make this short, I agree that there was a feature freeze, and that
> >one is necessary, but in the case of the email app, which was in need of
> >mainly finished Filtering support, I think that allowing it in, would make
> >the difference between .14 being a ok release, and a Great release.  I have
> >used the email app extensively in both .12CVS and .14RC, and it is lacking.
> >I might not be a developer on this project, but I think I can speak for
> >anyone that is considering phpgourpware for there needs, .14 would be a FAR
> >better release with the new "feature/bug fixes" that angles has done.. If
> >the project managements lets it in, I will update my system and bug test the
> >hell out of it, and report everything I can find, to make sure it is stable.
> 
> Well, I totally agree with what is said here. Angles has done a really great 
> job in the email part (I use it everyday for a few monthes now, I know it 
> very well). I understand the problem of feature freeze, but things put in the 
> email part are a really great improvment and would make .14 a great version 
> (and I don't underestimate the work done on other parts of phpGW !)
> 
> Maybe you could give bug testing for .14 a little more time ?
> 
> Just my opinion ...
> 

Let's hold on here.  I never said anything bad about Angles and his 
quality of work in this conversation.  I agree, Angles has taken the email
app to a new level.  My concern though, is that there are bugs in the
software, and some of those cannot be fixed at this point when certain
features are constantly shifting.  For instance, (remember, this is just
an example):  Every app that has options to SEND emails needs to use an
API call to determine the intended receiver's prefered email address.  I
cannot fix this until Angles is complete with his coding.  I had fixed
this a couple of times in the developement code (.13.0??) and it continues
to get mangled (create_email_preferences).  Right now I'm fighting
with the idea that the API is currently dependent upon the email app.
This makes no sense to me, that the CORE of the system is dependent upon
an app.  This is one of the reasons that a feature freeze is vital.  By 
locking in on features, everyone should feel confident that they are not
coding to moving standards.  Most people aren't really aware of this, but
there are other projects that are interested in what we are doing here.
The OOo, Open Offic Organization (Open Source Star Office) is very
interested in using phpGW as the backend server for their project.  For
this to occur, they have to write XML-RPC/SOAP calls to our methods.  Now, 
how can we feel confident to tell them that .14 RC1 is stable in the
exposed methods for them to build their native clients.

And to address one other point:  When the original feature freeze was
called for, and when I created the .tar.gz, .bz2, .zip, and .rpm files
there was in excess of 1 month between those dates.  By all accounts, 1
month is more than sufficient time to have features coded and added for 
inclusion.  And I remember it was just recently, within the last 5 days,
that issues were still being brought to everyone's attention.

Sorry for being such long winded.

Thanks,
Mark A Peters (Skeeter)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]