Guys - As an outsider this looks like a very small issue stemming from lack of coordination. It is absolutely something which can be taken care of by a little give and take and better understanding of each other's requirements.
Rob - I believe that a Blocker bug is by your definition something which jeopardizes a release. A kind of bug which 'makes' Gnash stop working at all or something similarly severe. Sandro - From your definition a Blocker is a bug of highest priority, which you want to address for Gnash to meet 'stability and quality benchmarks'. Which I think makes it a superset of Rob's definition. Starting from here, *Rob* why do not we let individual developers define the priority of bugs which they plan to work on or analyze. Since between release cycles the bug definition should not really matter greatly, as long as people pick it up. And *Sandro* since Rob is doing the actual release management, once he actually proposes a release date, let the team then decide which bugs are actually Blockers from the release perspective. With a realistic approach being how much can be fixed, given the team's bandwidth. If something is marked as a Blocker but is deemed too complicated or too isolated to affect a wide population, then the Release manager can as well degrade it. Since you have yourself done so in at least one case in 0.8.9 ( as you rightly did not want to hold up the release indefinitely), I think you would find this agreeable. This is just my suggestion, and you guys being long teammates would surely work it out. I hope I am not intruding. Dipto PS - It hurts to see so much pent up pressure in this team, which always seems to be at the edge of spilling out in the open. More so, since this Gnash team has some of the most committed and talented people in FOSS. To work to this extent purely voluntarily and produce such a great product, all of you need to take a bow. _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
