Re: Improving the handling of PR:s

On Fri, Jan 11, 2008 at 11:20:26PM +0000, Igor Mozolevsky wrote:
> On 11/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.

> Drawback: more work for the committers.
> Advantages: people feel rewarded for contributing patches, more
> hardware support...

Yes and others with fine running hardware feel unsure about it.
The result are new reports or just other users that run away.
It is up to the commiter to get the balance of things that likely
don't break other HW and those that are risky and need further
verification.
If it is considered to risky the commiter has to find others to test.
See the list for patches, which are published for public testing.
This happens for exactly the purpose that the commiter thinks it has
some risky nature.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd_at_bwct.de           info_at_bwct.de            support_at_fizon.de