On Fri, Apr 1, 2011 at 11:42 AM, Sandro Santilli <[email protected]> wrote:
Sure. > Only I'd do it during the release phase, after feature freeze, > and most importantly with a _team_ discussion. > > Fair enough. So if there can be agreement : The bug severity does not really matter in between releases (unless it is something which needs an immediate patch e.g. security). And it can be left to the individual developer looking into the bug. Rob I believe this should be fine since you as the maintainer cum release manager still do not want to expend time in micro managing the severity level of each bug. Best left to each developer's style and understanding, something which allows him/her to prioritise on their own. Before each release based on the tracker reporting, the team consensually decide which all bugs are release 'Blockers'. Based on - How much time it may need for analysis and fixing. What is the complexity? (Sandro I have no inputs on this one mate :-) You guys are the gurus so leave it best to your judgement) How big is the impact of the bug vis-a-vis overall Gnash usage. When the release needs to go out realistically. After this if some bugs designated as a Blocker are not fixable within the above constraints, let the release manager have a final say (in consultation with the person assigned to the bug) on what needs to be done. Whether delay the release or downgrade the bug. If the team can address these with honesty and is a little more accommodation for each other, think this may work. Cheers - Dipto
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
