| |||||||||||
|
| |||||||||||
2.6.0-test9 user2.6.0-test9 userPosted Nov 20, 2003 11:54 UTC (Thu) by keithw (subscriber, #3127)In reply to: 2.6.0-test9 user by rwmj Parent article: 2.6 patch policy This makes a lot of sense to me - and the evidence from previous releases backs it up. Why should development restart again even in a limited fashion after the first (.0) release? Why not do development in a development branch, and possibly backport stuff to the stable branch later on? The argument has been that there was a desire to have developers concentrate on the stable branch for a while prior to getting caught up in the new development branch - but it seems that the effect of this "concentration" is to reduce stability. If 2.6 goes straight into a stability-oriented regime, and 2.7 kicks off immediately, it might even bring down the time to 2.8 (well, maybe not...)
(Log in to post comments)
2.6.0-test9 user Posted Nov 20, 2003 15:48 UTC (Thu) by zander76 (subscriber, #6889) [Link] HelloGererally 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. Ben
2.6.0-test9 user Posted Dec 2, 2003 2:28 UTC (Tue) by leonbrooks (guest, #1494) [Link] So what you're saying, in essence, is...
2.6.0-test9 user Posted Nov 20, 2003 19:51 UTC (Thu) by Ross (subscriber, #4065) [Link] The problem with opening a new dev branch right away is thatthe stable and development kernels will diverge. This means that fixes in the development branch might not make it into the stable branch and vice versa. This happened in 2.4. In fact there are fixes in 2.4 which are still not in 2.6.0-test because of that.
2.6.0-test9 user Posted Dec 2, 2003 2:34 UTC (Tue) by leonbrooks (guest, #1494) [Link] You have to balance that against the fixes which didn't happen anywhere because the developers didn't bother retrying when they were rejected during the prerelease bottleneck, and against the patches which hit the kernel hard because they developed in isolation and arrived in big chunks when contribution was opened up again instead of developing in manageable nibbles over time.Also, I'm guessing that there are enough people working on the kernel now, and enough bodies practiced at kernel lieutenancy that we can well afford to open 2.7 the instant a 2.6.0-test1 is released.
|
|||||||||||