Hi !
This is a very interesting idea, but I think we will
quickly need two more types of information from the
patch sender :
- type of patch (fix, new feature, performance boost,
cleanup ...)
- the degree of reliability known to the sender :
- some patches are hand-coded (often proposals on
lkml)
- some *will* break something (just for test
purposes)
- some are known to be buggy, but testers are
needed
- some patches are simply not tested
- some are reported to work for a long time on a
small amount of computers
- some are reported to work, perhaps with small
bugs
(ie: raid, reiserfs, ide... mainly real projects)
- some are known to involve absolutely no risk at
all (mainly documentation patches).
I personnaly would like to be able to classify the
patches I sometimes send this way. I know that some of
them are not good and I wouldn't like people to
blindly
rely on them. With such a method, it would be easy to
select "reliable fixes" or "features that need to be
fixed" on a search engine.
Moreover, if a patch is finally reported to break
something, it would be easy to change it reliability
level afterwards.
If we also add a field that tells if the patch is to
be included, not to be included or simply proposed,
it would be helpfull to include synthetic reports
about
the global reliability.
Just my two cents here,
Willy
___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST