| |||||||||||||
Tightening the merge window rulesTightening the merge window rulesPosted Sep 11, 2008 13:57 UTC (Thu) by NAR (subscriber, #1313)Parent article: Tightening the merge window rules
There are a lots of complaints from kernel developers when someone dumps a whole lot of code on the kernel for merging (new filesystem, driver, etc.). The kernel people usually say that these developers should have worked with them from the point of typing the first line of the new code.
Of course, if development starts in the open, there is a push to merge it early to the mainline (so if someone changes yet an other internal API, the code will be automatically updated). However, code released early tend to contain lots of bugs that could be easily fixed - hence there's a contant flow of small fixes and new features and I guess is hard to stop this flow.
So I this problem is inherent in the current development process.
(Log in to post comments)
Tightening the merge window rules Posted Sep 12, 2008 10:28 UTC (Fri) by mingo (subscriber, #31122) [Link] The thing is, every new kernel project should start small and should aim for constant stability. Dropping a large amount of code on upstream with a large amount of open problems means the project has been done wrong from the get go. If a project starts small in the upstream kernel, it is not a problem at all to have a constant flow of updates - as long as they are stabilized and are merged in the merge window only. That's how the kernel evolves, gradually. A project that is in a constant state of breakage makes little sense.
Project flow Posted Sep 13, 2008 22:53 UTC (Sat) by man_ls (subscriber, #15091) [Link] Of course this is good engineering practice, but you will appreciate that it is not how software projects are usually managed. The usual process starts with a blueprint, then goes through to analysis and development and finally testing (at which point it's a huge mess of code which doesn't work at all). It takes months to get things working again.It has taken decades for a few people to value constant stability, and even so most of the world isn't there yet. So it is not strange that it should take a couple of years to get used to such a process.
Project flow Posted Sep 14, 2008 13:10 UTC (Sun) by mingo (subscriber, #31122) [Link] It has taken decades for a few people to value constant stability, and even so most of the world isn't there yet. So it is not strange that it should take a couple of years to get used to such a process.Yes, and even for the kernel it has taken almost a decade to reach that state. (Btw., the technological trigger was Git - it enabled the new, distributed, "evolving" workflow.) So shouting at folks for not getting it right would be rather hypocritical, and in practice upstream is rather flexible about it all. The comment i replied to claimed that there was a problem with the kernel's development process. I disagree with that, and i think it's natural to expect that if some code wants to reach upstream ASAP it should try to follow and adopt to its development flow. I.e. new projects should 'become upstream' well before they touch upstream (they should adopt similar principles) - that way there will be a lot less friction after the merge point as well.
Project flow Posted Sep 15, 2008 14:43 UTC (Mon) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
> The usual process starts with a blueprint, then goes through to
> analysis and development and finally testing
For my small projet, I have just coded so that I knew exactly what
Etienne.
|
|||||||||||||