Regarding [Bug 6426], [Bug 6544], and some other similar ones, suggested to be closed by Darxus. These are problem reports (often opened by me) to document some new feature or some bug fix requiring a more extensive fix. As the trunk is in the CTR mode, the changes were already commited to trunk, have been tested at least by me, and are in productiion use by those sites which have chosen to run trunk code in production (because release cycle have been so slow lately and the trunk has actually been more reliable/stable than 3.3 or 3.2).
These problem reports are mainly opened for documenting the change, and for soliciting any violent opposing votes :), so keeping them open for a while is probably a good way to let developers be made aware of new features. In C-T-R mode we eventually arrive to the R (review) phase. We could adapt a more practical stance, and consider the final vote for some release version to imply a review/approval of any changes that have been commited so far - assuming the changes were documented and their tickets open for some sensible time period. We have probably followed this approach occasionally in the past. I'm fine with this approach, I just don't think it follows the published procedure to the letter. So, taking [Bug 6426] and [Bug 6544] as examples, what is a sentiment about such? Just close after the change has been commited to trunk for some time, or should we follow a voting procedure for each open problem report? Mark
