> A "small stuff" maintainer may indeed be a good idea. The maintainer could
> be the same as somebody who does bigger stuff too, but they should be
> clearly different things - trivial one-liners that do not add anything
> new, only fix obvious stuff (to the point where nobody even needs to think
> about it - if I'd start getting any even halfway questionable patches from
> the "small stuff" maintainer, it wouldn't work).
So if someone you trusted actually started batching up small fixes and
sending you things like
"37 random documentation updates - no code changed", "11 patches to fix
kmalloc checks", "maintainers updates to 6 network drivers"
that would work sanely ? I think that would actually fix a lot of the stuff
getting lost right now. Its mostly small stuff, often from new people, or from
folks who met a bug, fixed it and have a totally seperate and rather more
important (to them) project and deadline to meet that is going walkies.
It also increases bandwidth for sorting out the big stuff.
The other related question is device driver implementation stuff (not interfaces
and abstractions). You don't seem to check that much anyway, or have any taste
in device drivers 8) so should that be part of the small fixing job ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:16 EST