Time for a 4.8.4 release

[Daniel Morissette]

Stephen Woodbridge wrote:
> 
> but WHEN is the time to ask for fixes or to review open bugs for 
> potential inclusion in maintenance releases. 

There is not really a set time to discuss bug fixes for maintenance 
releases since there are no set time for maintenance releases, we just 
do maintenance releases when we feel there are enough bugs in the stable 
CVS branch to warrant a release. If there are bugs you feel should make 
it in a maintenance release then they should be discussed as early as 
possible, and preferably not when there is a proposal on the table to 
release the current (committed) fixes.

If you take 4.8.4 for instance, we released 4.8.3 on March 30th, so 
anytime between March 31st and 2 days ago would have been a good time to 
discuss/fix bugs. Today is not a good time because there is a proposal 
on the table to release the current CVS code as 4.8.4.


> There is never any urgency 
> around fixes until someone talks about a release. 

True, and that's the habit I am trying to break.


> I don't think these 
> are so much favorite wishes as much as legitimate request for known bugs 
> to be fixed.  I'm happy to debate if a bug should or should not be part
> of a major, minor or dot release.
> 

Please keep in mind that pointing out that a bug should be fixed for a 
given release (or even voting a motion to that effect) doesn't 
necessarily mean that it will get fixed. You also need one of the 
developers to take the time to do the actual work (or review/apply a 
patch and vouch for it), and this happens only if this bug gets high 
enough in one of the developers' priority list.

Another important point to keep in mind when considering bugs for 
maintenance releases is that we should never commit new features to a 
stable branch: only critical fixes. New features can only go in the main 
development trunk. This is to keep the stable branch as stable as 
possible. I'm not arguing that the bug that you (SteveW) raised was a 
new feature, I'm just reminding everyone of that rule from RFC-7.

<hint>
If some bugs systematically fail to be addressed then it is likely that 
they are not high enough in any developer's list. If a bug is a high 
priority for someone then one way they can influence priorities is by 
offering one of the developers to fund the fix. Most of us keep our 
paying clients at the top of our priority lists and will address bugs 
for them within days (or within hours when possible).
</hint>

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/