...and what would you do with such information?
I'm not actually worried about my tree but if (theoretically) it happens to
be amongst the "problematic" ones I would be a bit pissed by blame shifting,
especially given that it is very difficult to compare different trees as
they (usually) deal with quite different areas of the code (some are messy
and problematic, yet critical while others can be more forgiving).
Also slowing down things to focus on quality is really a bad idea. You can
trust me on this one, I've tried it once on the smaller scale and it was a
big disaster cause people won't focus on quality just because you want them
to. They'll continue to operate in the usual way and try to workaround you
instead (which in turn causes extra tensions which may become quiet warfare).
In the end you will have a lot more problems to deal with...
Same goes for any other kind of improvement by incorporating "punishment" as
the part of the process. You are much better helping people and trying them
to understand that they should apply some changes to their way of work because
it would be also beneficial for _them_, not only for _you_.
Now regarding the development model - I think that there is really no need
for a revolution yet, instead we should focus on refining the current process
(which works great IMO), just to summarize various ideas given by people:
- try to persuade few black sheeps that skipping linux-next completely for
whole patch series is a really bad idea and that they should try to spend
a bit more time on planning for merge instead of LastMinute assembly+push
(by doing it right they could spend more time after merge to prepare for
the next one or fixing old bugs instead of chasing new regressions, overall
they should have _more_ time for development by doing it right)
- encourage flatting of merges during the merge window so instead of 1-2 big
merges per tree at the beginning of the merge you have few smaller ones
(majority of maintainers do it this way already)
- more testing for linux-next, distros may be of a great help here (-mm and
-next often catches bugs that you wouldn't have ever imagined in the first
place and they get fixed before the problem propagates into Linus' tree)
- more documentation for lowering the entry barrier for people who would like
to review the code (what Al has mentioned in this thread is a great idea
so no need for me to repeat it here)
- more co-operation between people from different areas of the code
(i.e. testing linux-next instead of your own tree)
and just not to forget - changes happen by people actually putting the work
into them not by endless discussions.
Thanks,
Bart
--
