fre 2012-08-17 klockan 16:03 -0600 skrev Alex Rousskov:
> The above policy places places a 24 hour wait time that may not be
> appropriate in emergencies. On the other hand, it may be interpreted as
> a permission to revert any change that a person considers "broken" after
> 7 days of squid-dev discussions, which may result in painful and
> unnecessary reversals.
If 7 days of discussions and attempted fixing can not fix the code to an
acceptable level then it's not yet ready for trunk and should go back to
live in a developer feature branch and resubmitted for merge when in
better shape.
> (a) Balances the reversal effects with the effects of keeping the broken
> code. For example, reversing a high-demand but optional feature that
> breaks a default farm build on an obscure platform may not be such a
> good idea. On the other hand, reversing a commit that breaks build on on
> all platforms should not be frowned upon, especially if error reports
> are not followed by immediate fixes (indicating that the responsible
> party is unavailable to fix things promptly).
It's very hard to say exactly where the limit is. For as long as that
code breaks that "obscure" platform the build tests for other code on
that platform is offline. Repeat this a number of times and we soon have
no platforms that builds.
> (b) Details the reason for reversal so that the responsible party has a
> reasonable path forward to fix the problem or object to the reversal.
> For example, "does not seem to work for me" is a bad reversal commit
> message, but "breaks 'make check' on Fedora, with the following error"
> is a good one.
Agreed.
> Since "balance" and "broken" are relative terms requiring judgment
> calls, most reversal decisions should be driven by squid-dev consensus
> except in emergencies.
I do not see reversals of trunk changes as such as that intrusive to the
development process. Not even when it's a bit older commit.
But we need to get the hang of how to handle this proper in bzr so that
the reversal propagates only to the development branches where it should
propagate.
Regards
Henrik
Received on Sat Aug 18 2012 - 00:09:16 MDT
This archive was generated by hypermail 2.2.0 : Sat Aug 18 2012 - 12:00:07 MDT