RE: [phpBT-dev] RE: [Phpbt-users] Bug fixes or features?

[Ulf E. <ulf...@fa...>]

> > I'm thinking of "stability" in areas such as the database 
> > schemas and the translatable strings.. 

Considering that v1.0.1 has been released with a small fix it might be
possible to talk Benjamin into accepting more fixes for a stable 1.0.x
series. I've got a few patches in the pipeline waiting for comments..

> > I have only used phpBT for about half a year, but looking at 
> > the mail archives it is clear that it took over a year to go 
> > from rc1 to final release of v1.0. Still, half the 
> > translations from 0.9 had falled out together with support 
> > for Oracle. 
> 
> (Just thinking out loud): A database abstraction layer might be nice.  

Currently Pear:DB is used, but it doesn't abstract much more than the
API calls. You must handle all differencies in SQL dialects yourself.
phpBugTracker isolates them in a set of inc/db/*.php files. One for each
dialect.

I think SQL-Fairy should be able to translate an SQL-query from one
dialect to another. Maybe that would be a way to help translate our
queries?

> > Yes, downloadable bundles would have to be offered at 
> > strategic points.
> > Testing could then be focused on the newly added/repaired 
> > parts. Any chance you can help with a test plan? Something 
> > simple with a bit of a guideline for new testers.
> 
> I am keen to see this project gather some momentum again.  Count me in :)

Great:) What support would you need to help out the best? I guess you
would have no problems gaining web or cvs access from Benjamin. Maybe
information over what goes on in the codebase today, future plans, etc.
are as important? Would the phpbt-dev mailing list be a good channel for
such?

> > >  * What new features would you expect in a new release?
> > > 
> > > Should we set up an opinion poll for all users to contribute their 
> > > thoughts to?
> > 
> > Sounds good. Ideas on how to handle it?
> 
> Well, I don't mind coding a PHP-driven questionnaire, but the real
> question
> is how to structure the questions.

I tried to start with an open question :) Is there anything seriously
missing?

There is also a list of already requested features at sourceforge.net. A
voting session could help to determine what is most wanted.

> I don't really think there is a golden rule here. One way the testing
> could
> be approached is risk-based: Use a forum, where developers express
> concerns
> over the areas that they perceive currently have the greatest risk -
> consequently, more testing effort can focus in that area.  

Do you have any experience in automated testing tools for web
applications? I would guess that much of the basic functionality could
be tested that way to quickly detect changes that seriously break
something else.

> It really depends how much creative freedom developers are allowed - the
> more they want, the more fluid testing must be (And the harder it is to
> manage).  The more structured/controlled the dev process, good testing
> becomes more manageable.

Benjamin once mentioned that he would like to use test driven
development if he had to start all over. I'm pretty sure that you can
get support for a more controlled development process if you in return
help managing the tests.

-- 
Ulf