Re: {painfullyBISECTED} Please revert f25c80a4b2: arch/um/drivers: remove duplicate structure field initialization

[Emil Langrock <emil.langrock@gmx.de>]

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

> The real problem is that maintainers often pick random - and not at
> all stable - points for their development to begin with. They just
> pick some random "this is where Linus -git tree is today", and do
> their development on top of that. THAT is the problem - they are
> unaware that there's some nasty bug in that version.
> 
> It's actually made worse by rebasing. A lot of people end up rebasing
> on top of such a random kernel (again, just because it's the 'most
> recent'). It's very annoying.
> 
> Not to mention that rebasing easily results in bugs of its own, when
> you do hit merge conflicts or double-apply something that already got
> applied (and wasn't seen as a duplicate and merged away automatically,
> because the code had been further modified since). We had that in the
> DVB pull request just yesterday.
> 
> > So in short this is a call for, possibly, cleaner History in main Kernel.
> > Please remind me why re-writing history is a bad thing.
> 
> Rebasing doesn't result in cleaner history. It just results in
> _incorrect_ history that looks simpler.
> 
> To get cleaner history, people should try to keep their tree clean.
> Not add random patches to random branches, and not start random
> branches at random points in time that aren't necessarily stable.

I understand what you want to say, but I don't see how you define stable points. 
Maybe you mean that a stable point is a non-rc release of Linux. This of course 
sounds like a good idea when you start a complete new development without any 
dependencies, but think about following events (ordered by time of event):

 * v2.6.37 was released
 * foo starts to code the feature bar
 * foo asks a subtree maintainer to merge his stuff (subtree maintainer doesn't 
merge it because 2.6.38-rc1 wasn't released yet)
 * v2.6.38-rc1 was released
 * subtree maintainer merges the commit because we need more bar in Linux
 * v2.6.38 was released
 * subtree maintainer asks you to merge his tree with the cool bar feature
 * foo wants to extent the bar feature to superbar and get it in 2.6.40
 * v2.6.39-rc1 gets released with the cool bar feature
 * v2.6.39 gets released with the final and bugfixed bar feature
 * (your merge window - time were foo will not be able to get new patches to the 
subtree maintainer for v2.6.40-rc1)
 * v2.6.40-rc1 gets released

Even if this is a relative small example and the usual problem is more complex - 
what starting point should be used for his superbar feature? My obvious answer 
would be 2.6.39-rc1 (but is it really a stable starting point?)

Kind regards,
Emil Langrock