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: Ryan Bonham
Subject: Re: [Phpgroupware-developers] darn near email done, merge notification (fwd)
Date: Sun, 3 Feb 2002 18:22:15 -0500

Skeeter,

I don't think anyone thought you were questioning Angles quality of work. I
think our only concern, as users, was the fact that the email app was
desperately in need of the changes Angles has done. I have been and will
continue to try and find any bugs in the email app, and any where else I
find them. I didn't know that API was dependant on the email app, which I
know some of the developers don't want the email app changed. That is
something I simple didn't know as I haven't been spending my time learning
the API and how the apps work, perhaps I should, but I don't think I have
the time to learn that, I feel it is a better of use of my time trying to
find problems. Even with the knowledge that the API is dependent on the
Email, I still ask that the developers weigh the advantages of the new
"features" that angles has working, to the disadvantage of extending the
debug time a little.

Ok, I will stop rambling now.

Ryan Bonham

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




reply via email to

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