Re: [Gnash-dev] Time limit on fixing regressoins in the CommitRules?

[Petter Reinholdtsen]

Anyone got an opinion on this?  Rob?

[Petter Reinholdtsen 2014-01-16]
> The current set of commit rules,
> <URL: http://wiki.gnashdev.org/CommitRules >, state as rule 3 that
> "Commits shall not be reverted except as a last resort", which in
> general seem like a good idea to bring the project forward.
>
> But the introduction of a regression last June, and the bugs #39989
> (2013-09-09) and #40315 (2013-10-20) reporting the regression, make me
> suspect that perhaps it is best to add some time rule about how fast
> regressions should be fixed before the change is reverted instead.
> What about extending the commit rules with a new rule, along these
> lines:
>
>  * Regressions / crash bugs introduced after the last release should
>    be fixed in the master branch within one month of their discovery.
>    If no-one are able to fix them in that time frame, the change is
>    reverted until someone have time to fix it.  Please add new
>    testsuite tests to detect the regression / crash if such test do
>    not already exist.
>
> The person introducing the regression should have an extra
> responsibility to fix the problem, but given that this is a community
> project I believe each of us share the responsibility.  Unfortunately,
> in the issue mentioned above, I lack the skills to fix the patch, and
> can only propose to pull it out until someone with the required skills
> have time to look at it.

As you probably have seen in the last emails, the regression that
triggered my email lasted for june last year and to yesterday.  This
seem like a bit too long for me, as it as far as I can tell blocked our
ability to make a new release the last few months.

-- 
Happy hacking
Petter Reinholdtsen