Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
if you have the same people producing the commits and the patches they will probably have the same quality.
Updating and rebuilding Android
Posted May 7, 2009 23:47 UTC (Thu) by nbd (subscriber, #14393)
If you're working on two separate features in an OpenWrt package, the build system generates a quilt patch stack for you to edit, which makes it very easy to keep things separated. This means the system actively encourages you to keep things organized by not forcing extra work on you to do the right thing.
If you maintain such a tree in git and you want to make changes to a feature that you already committed, you're either forced to rebase (which is bad for everybody that's pulling from you), or you have to live with the fact that the grouping of changes is lost in the process.
It does not only depend on the people working on it, but also what the tools encourage you to do, and especially what the common workflow of the tools you work with is.
Posted May 8, 2009 7:26 UTC (Fri) by dlang (✭ supporter ✭, #313)
if you need to change one of the features you make a change in that brance and do another merge.
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