Posted Nov 20, 2003 15:48 UTC (Thu) by zander76
In reply to: 2.6.0-test9 user
Parent article: 2.6 patch policy
Gererally I dislike the idea of starting a new branch straight away and there are a few reasons for this.
1. Its more fun to work on new stuff but the bugs really should be fixed.
2. Gives people a break, its not so much that people want a break but its a good idea to have one. You get a chance to really look at the current implementation and see people responces to it over a long period of time.
3. Gives all the maintainers a bit of a break, they still have to take in bug fixes but not as many when you compair it with taking in bug fixes and new features.
4. Gives everybody a bit of a planning state, people will start talking about new ideas and hash them out, but they aren't going in anytime soon so they can really give it some time and though. Usually there is some form of a conference were hackers can get together and work out ideas for the next release.
You have to keep in mind that most of the patches that are waiting are bug fixes and minor changes. The problem with these is they have a chance to introduce new bugs. They will have to go in, but if he starts putting them in now then we will never see a new version. So yes its true that after the new release things will become less stable because they will start allowing bug fixes in again, partly due to the backlog of patches and partly due to the fact that a lot more people are using it and they are finding more problems.
So yes it does seem like the kernel becomes less stable for the first few kernels but taking the developers away from it is not the correct solution. Having a 2.6.0 kernel that is stable is a completely different thing then having a stable kernel that works for everybody. 2.6.0 will be stable for people with specific machines and configs (to some degree) but 2.6.5 will be quite stable for everybody. To me that is the only way this could work.
to post comments)