Recent Features
| |||||||||||||
Updating and rebuilding AndroidUpdating and rebuilding AndroidPosted May 7, 2009 22:42 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Updating and rebuilding Android by nbd Parent article: Updating and rebuilding Android
the android people are accessing everything through git, so their 'forking' is not significantly different from your 'maintaining patches' (you have less stuff to move around, they use a tool that helps them merge with the original and provides them with some safety in terms of their changes still being correct)
(Log in to post comments)
Updating and rebuilding Android Posted May 7, 2009 23:10 UTC (Thu) by nbd (subscriber, #14393) [Link]
It is different in that the OpenWrt patch structure encourages splitting up changes in a way that makes review for upstream merging easier.
Looking at random Google-forked git directories, all I see is uncommented auto-import commits without a readable commit message, without any indication as to what the changes are meant for or why they were added. Stuff like that does not usually happen in OpenWrt-maintained patchsets. I looked at jpeg, libxml2, bzip2 and a few others, and I found no useful information that could help with upstream merging at all.
Another issue is that in the android build system, you cannot build packages without making changes to them (you have to at least throw in some Android.mk files to replace the Makefiles), while in OpenWrt you can leave many packages as-is and use them with our package Makefiles and no patches at all
Updating and rebuilding Android Posted May 7, 2009 23:34 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you can have a patch with a lousy explination, just like you have have a git commit with a lousy changelog. it's not a technical problem.
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) [Link]
Here's an important difference:
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.
Updating and rebuilding Android Posted May 8, 2009 7:26 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
no, you do your two different changes in different branches and then merge the two togeather.
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) [Link]
Who actually does that?
Updating and rebuilding Android Posted May 8, 2009 9:47 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
the impression I get from watching projects that use git extensively is a lot of people.
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.
Updating and rebuilding Android Posted May 8, 2009 10:09 UTC (Fri) by nbd (subscriber, #14393) [Link]
What you describe still doesn't quite cover the amount of feature separation that I'm talking about. Yes, when you start implementing a feature separately, you still have some degree of separation by keeping it in a branch, but once you start pulling stuff into your master branch and merging back and forth between the master branch and the feature branches, that becomes lost too.
Or what about switching to a newer upstream version? Sure, you could go ahead and first rebase every single feature branch individually, then try to merge them back in the same order that they were merged initially (if you even kept that information and assuming that you didn't touch the same code parts in different branches), but again that's much more expensive than keeping a set of simple, readable patches around in the first place.
To sum things up:
In my opinion those differences are quite significant
Updating and rebuilding Android Posted May 8, 2009 10:18 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
you don't merge back from the main tree to the feature branch.
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)
Updating and rebuilding Android Posted May 8, 2009 10:31 UTC (Fri) by nbd (subscriber, #14393) [Link]
Really simple:
If the system lets you get away with having to do less changes to a package to get it working, then *of course* there are going to be fewer changes. People want to get stuff working, and make only the necessary changes. Or are you really saying that build system and structure have *no* influence on the result? My experience says otherwise...
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.
|
|||||||||||||