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 :-/Received on Fri Jan 11 2008 - 23:25:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC