Eric Rescorla writes:

> I don't believe I am asking for this, just auto-squash on submit. I
> certainly understand if it's your position that you have higher priorities,
> that's fine, but it's not fine to remove the ability to do squashed reviews
> before something like that lands.

Perhaps the distinction between the processes here is that it is
typical in Mozilla process to attach several logical changes to
one bug report if they are all required to fix the single bug.
Filing dozens of bugs can become unnecessary overhead if
changesets are going to land together anyway, but there can be
advantages to multiple bug reports, when backouts or uplifts are
required, for example.

I assume none of us want different logical changes in one
changeset.  This makes reviewing and regression tracking harder. [1] 

auto-squash on submit of course would not be fine for different
logical changes on one bug report, without some mechanism to
describe which changes are evolution-during-development, to be squashed,
and which are separate logical changes, to remain separate.
The current model relies on the submitter to make the distinction.

Often it is helpful for reviewers to be able to see the final
state, including all logical changes.  Being able to do that is
one of the benefits of push-to-review systems.  I assume the
intention was not to remove that view, but to remove implication
of a single review request for all logically-independent changes.

[1] 
https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/#many-small-commits
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to