Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
if you need to change one of the features you make a change in that brance and do another merge.
Updating and rebuilding Android
Posted May 8, 2009 9:38 UTC (Fri) by nbd (subscriber, #14393)
Posted May 8, 2009 9:47 UTC (Fri) by dlang (✭ supporter ✭, #313)
remember that branching and merging is very cheap with git, keeping the separate development parts in separate branches lets you test them individually. it's only after you are sure that they are a permanent part of your central branch that you throw them away.
there are people who create separate branches for every different topic that they work on, even if they think it's only going to be a single patch.
Posted May 8, 2009 10:09 UTC (Fri) by nbd (subscriber, #14393)
To sum things up:
- it is possible to do this with git, but it's more work and requires more discipline
- devs at google did not have time to do this part right, thus the result is a set of forks that due to their structure are not easy to merge back upstream
- even with patches or commits from less experienced developers, the same chaos does not happen in openwrt packages
- in openwrt you can get away with not having to fork a lot packages
- in android you have to fork every single package and if it's just for replacing the makefile with an Android.mk file
- in openwrt you have to pay less attention to how a package works internally, most autoconf based stuff can be handled with very few changes compared to a template makefile (often only changing the package name, description and download location)
In my opinion those differences are quite significant
Posted May 8, 2009 10:18 UTC (Fri) by dlang (✭ supporter ✭, #313)
but the point is that I don't believe that the people who created the commits that you are complaining about would have done any better if they were patches. there was nothing in the tool that prevented them from doing things better. there are lots of kernel developers who would have helped them develop things (and comment them) if they had asked, but they weren't willing to reveal things.
getting things in patches would have probably been _far_ worse, as there would probably just be one big patch for each program (that _is_ the common thing to do when companies fork programs and then release their changes)
Posted May 8, 2009 10:31 UTC (Fri) by nbd (subscriber, #14393)
About making things public and involving kernel people: Yes, that would have helped for getting changes upstream, but it would not have helped to get the product out faster. The Kernel developer community is focusing on getting it done right, while their own development team has to focus on getting it done fast (or at all). Considering the amount of pressure on getting stuff to the market fast, there's only so much time you can spend on figuring out the right approach...
So how would getting things in patches have been far worse, if the patches themselves are under version control? Having patches under version control means that you have *at least* the same amount of information available that you have now, but with an extremely easy way of structuring things even more if you feel like it, which (using quilt) costs virtually no extra effort.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds