tor 2012-08-16 klockan 23:11 -0600 skrev Alex Rousskov:
> I am not annoyed at the failures -- we all commit broken code once in a
> while, and there is currently no good way to prevent even simple build
> failures.
Yes..
> I am somewhat annoyed that some failures result in commit reversal (with
> unusable or contradictory information as to the reason for the reversal)
> while others are not (even after detailed reasons have been provided),
Reversals are not routine. There is no automatic reversal, instead it is
up to each and everyone to decide on when reversal is appropriate and
when not.
Ok, here is a proposal on a little policy on the topic on how to handle
others bad commits:
trunk:
1. If possible, fix it.
2. If not, nag the person who committed the problematic code.
3a. If no response in 24 hours and it's blocking other things (including
test farm builds) then revert the commit with a notice to squid-dev.
3b. If still broken after 7 days of discussion and attempts to fix then
revert the change.
4. Let it mature in a development branch, and submit for merge again
when the issues have been resolved.
numbered branches:
1. If possible, fix it.
2. If not, nag the person who committed the problematic code.
3. Let the release manager decide on reverting
It's a real pity bzr do not have a "unmerge" operation. Currently
reversals are quite intrusive and may merge to the branch where the
feature was developed erasing it from there as well.
> but this is _not_ the reason I am asking who is responsible for fixing
> trunk -- I do really need to know whether this is something I should be
> working on (to avoid two different people working on the same bug).
"responsible".. is the one who takes on the bug in question.
Regards
Henrik
Received on Fri Aug 17 2012 - 16:49:53 MDT
This archive was generated by hypermail 2.2.0 : Sat Aug 18 2012 - 12:00:07 MDT