Improving the handling of PR:s

[Igor Mozolevsky]

On 12/01/2008, Bernd Walter <ticso at cicely12.cicely.de> wrote:

> > > Another point about hardware is that a patch might influence other
> > > hardware handled by the same driver, which can't be verified by the
> > > submitter nor the committer.
> > > This is especially true with workarounds, which might only be required
> > > for specific chip revisions.
> >
> > Which can only be verified/fixed once the patch is merged into a
> > branch and new PRs are filed, if everyone used the approach of "let's
> > not touch it because something might go wrong", nobody would fly
> > because they might be involved in a plane-crash (of a similar model of
> > a plane, just slightly different configuration)...
>
> Planes are different to chips - they are documented well.
> You can't try and false on patching within the tree.
> Errors can happen, but you have at least do the best to avoid bad
> effects on hardware which runs fine so far.
>
> > The procedure would be effectively:
> >
> > patch->commit->[fixed|PR->limit the scope of the patch->commit]+
>
> Hardware doesn't always work this way.
> A fix for one HW can break another.

Which is why is said *PR->limit the scope of the patch* part!

Igor :-/