Hacker News new | past | comments | ask | show | jobs | submit login

This seems like the natural lifecycle.

1. There are many features that we feel very valuable to our OS, so we will implement them and ship our OS without blocking on upstream approval and acceptance. 2. Maintaining these patches is expensive. We will try to upstream as much as possible. 3. Most of our patches have been upstreamed and most new kernel requirements are lower priority, we should prefer to upstream first to reduce the cost to migrate our OS from the original implementations to the upstreamed implementations.

At no point does it seem that the decision was "wrong". Obviously carrying a bunch of patches has downsides but at the earlier points in the OS lifecycle getting the features was probably much more valuable than the downsides were harmful.




This lifecycle also has the natural benefit of letting the earlier, more product essential patches stew and iterate for a bit before finally maturing and being pushed upstream. Nobody in the process wants to revisit a big patch a couple months after finally getting something upstreamed to find that 70% of it has been replaced by something better or different, and now the upstreaming of that is a big pain and causing kernel churn. Letting big stuff mature in a large extra-kernel ecosystem (such as android) is good for everyone (as long as it actually does make it into the kernel eventually if it's good).


I remember Google went through much the same process with their own private server kernel fork.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: