You need to log in before you can comment on or make changes to this bug.
All, I would like to start chameleon onto a release cycle with the intention of getting version 1.1 released by Christmas or early in the new year. We have a lot of interest in chameleon right now and I think delaying a release will only hurt us in the long run. That being said, the purpose of this bug is to track the tasks required to get a Beta release of Chameleon 1.1. My intention with a Beta release is to: 1. freeze changes to the core of chameleon. 2. identify widget groups and their status (beta, alpha, development) with respect to chameleon 1.1 3. thorough review and QA on the chameleon core and base widget groups (those that are considered part of the chameleon package) With this in mind, I need feedback from the chameleon developers on outstanding features that need to be implemented. AFAIK, the list is: * Sacha to implement support for handling widgets in multiple forms * Paul to implement complete buttonizer/button support in widget.php, including non-javascript mode for buttons * Darren/Sacha/Paul to redo widget documentation architecture (already in bug 74) Once these (at least the first two) items are complete (and any others that get added), I would like to do a code review of the chameleon core components, including: * chameleon.php (522 lines) * UIManager.php (427 lines) * WidgetManager.php (183 lines) * TemplateParser.php (248 lines) * Widget.php (925 lines) As part of this, I would also like to review the current contents of the configuration files for chameleon and validate all the items there. This represents a fair amount of code, and could take quite a while to thoroughly review. I think this is an important step, though. Once this is done, I think we can move to a beta status and then begin to use bugzilla extensively to report and track remaining issues for a full release. Comments are welcome. Also, who should be on the code review and when should we do it?
I think it is a very good idea. This Chameleon stuff really seems to be catching on. For myself, I would like to be in on the code review. I have developed a number of widgets but would like to get an inside look at how the base widgets really work.
Here are some hints that can help for the code review : - limit the number of people to 3 to four (the code owner + couple of people) - target time for the meeting should be 1h or less - code owner should be responsable of preparing (printing the code to review with line numbers) and give it to the others (at least a couple of days before. - we could setup 1 code review per week at the same time (maybe a wiki page indicating the code reviewed and the persons attending). Every body should atleast be a review and a reviwer at least once. (People not on the review list but are interested could add themselves to the list) - the sceduling should be a growing list and should be updated every time a new code (or at least a critical peice of code) is added. - the main point is to determine what the review should include. Here are some hints : * optimization * errors/potential errors * design flaws * code convention - tracking of the code review : this could be done in at least 2 ways : * if there is not much to change, It could just be the responsability of the review to take notes and update the code * if there are a lot of things, this could be entered as a bug with details of changes.
Bugs with too many items in them tend to become confusing and almost impossible to keep track of. Instead I would recommend using separate smaller bugs that are easier to track and then indicate proper dependencies. So the current bug becomes a tracking bug for the 1.1 release, and the following bugs have been filed as blocker tasks for this bug (please add more as required): bug 74 - Docs issues bug 93 - support for multiple forms bug 94 - buttonizer/buttons stuff
Is this bug still valid ? Or maybe just the title should change ? As far as I know, 1.1 is released ?
Forget my last comment. :$
Sacha is correct, the summary needed updating. I am not going to add the bug dependencies right now as that will generate (a lot of) noise from bugzilla whenever anything changes. All bugs for the 1.99 release are marked with a Target Milestone of 1.99 beta release.
updated version to 1.99
changing target to "-", since "1.99 beta release" is no longer valid, since it is to general. Paul and Darren should decide at which point during the beta release cycle this should be resolved.
updated to track 2.0 final release. When 2.0 is released, this should be closed.
forgot to close.
