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

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

* "Steve Dowe - Cubus" [2005-09-12 15:45 +0100]:
> > (snip) Playing nice and maintain a 
> > stable branch will most likely pay off in the end.
> 
> I think it's important to aim for stability, but in my experience, > there has been little to suggest it is particularly "unstable".

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

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. 

A stable branch would allow "low-risk" upgrades. If it used to work it
should still work; only better.

> Going back to the original points, here are my opinions (and please note,
> they apply to a pre-1.0 release as that's what I use):

If it is older than rc5 you might want to upgrade to avoid some SQL
injection issues.. I hope to improve on the input validation and
permission enforcements one day -- phpBT still relies too much on the
html template to handle such.

> * Should we fix bugs in the 1.0 release and offer regular updates, or
> should we spend all energy on developing a new version?
> 
> Are there specific requirements for a new version?  Have users registered
> their wishes?  If there are many feature requests (in terms of time
> required
> to implement), than I'd suggest fixing only "showstopper" bugs in 1.0
> then
> moving on.  If there has not been "significant" interest in new features,
> better to fix the older one - again, only if there's an outcry for fixes. 

I have made some changes since the 1.0 release and plan to do some more.
It is mainly things that i feel that I need. Some of the ideas I have
found in the list of feature requests:
http://sourceforge.net/tracker/?atid=364939&group_id=14939&func=browse

My interest lies in a more functional phpBT 1.x, but I don't mind
contributing towards a less buggy 1.0.x. I do mind however spending a
year with a locked-down CVS waiting for others to finalize the last
translation or database schema. Especially if that doesn't happen, as in
the v1.0 case. If that's the phpBT tradition I rather maintain my own
in-house fork..

>  * Should the development version be offered as a downloadable snapshot 
>  as
> soon as possible, or should we wait until it is safe and stable enough
> for
> a release?
> 
> As a software tester, I prefer the idea of releasing at key milestones.
> This
> could be to registered beta testers who have expressed an interest in
> fault-finding.  

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'm not too sure about forcing testers to register.. Wouldn't that cut
their number down from few to very few?

>  * Is the current development version safe and stable (and feature rich 
>  and
> bug free) enough for a new release?
> 
> Yes, it is here.

I meant CVS head.

>  * 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?

>  * What old bugs would you expect to be fixed in a new release?
> 
> I would expect all *known* old bugs to appear fixed in any new release,
> in
> addition to functional improvememts. :)

Of course. But the bugs that I know, the ones I can reproduce and
confirm, are not the same as the ones you know. There are too many
different Os:s, web servers, database servers, mail servers, and web
browsers (each one of those applications in different versions and
configurations) together with the php versions and configurations, pear
versions, and maybe more.. 

If you know some bug you must say so, it might not be known to everyone.
The list of old bugs are surely not all "known" by me:
http://sourceforge.net/tracker/?atid=114939&group_id=14939&func=browse

-- 
Ulf