On 4/5/07, Ben Warren bwarren@qstreams.com wrote:
Jerry,
On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:
If we use branches:
- Primarily used in the custodian trees: a) Useful for keeping track of work in progress b) Specifies what Wolfgang needs to pull into the mainline
- Must be kept clean - delete ones no longer useful
- VERIFY/merge with the mainline BEFORE requesting a pull. If Wolfgang finds a pull requires a merge, YOU HAVE FAILED as a custodian (or u-boot's world has shifted under your feet - probably the latter;-)
I see 1b) as being very important. Wolfgang has been VERY responsive for pull requests (THANKS!) compared to the pre-custodian days. If it takes more than a few days to pull a set of changes into the mainline, branches are the only practical way to keep track of what is pending. Trying to say "pull from 7cd5da0fe877e7171a4cdd44880bce783132871a to aea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit of a paper tiger).
I think I'm more in agreement with Wolfgang on this. The master branch should be what he pulls from, and code there should be expected to be ready for inclusing in the main tree.
I was thinking of using branches for less trivial changes. For example, if somebody submits a new driver, the custodian would put in on a 'testing' branch after it passes coding style and peer-review of logic. He/she would then send out an invitation for testers. After the custodian and others are satisfied, the branch is merged with master, and a pull request is made to Wolfgang.
Branches could also be used for more radical re-factoring efforts. For example, I'm not very happy with the mess that is 'eth.c', with all its #ifdef-wrapped initialize() functions. When time permits, I'd like to do this in a cleaner way and invite others to help out with design/coding/testing. Another example is the work Grant's doing on the memory commands. It seems to me that branches are the way to go here.
Maybe I'm over-complicating things. Maybe we're all really in complete agreement and I just didn't parse your ideas properly. Stranger things have happened...
I have some patches in hand, and they are not common enough to be committed into mainline, but they are really useful for the user. So, I'm thinking, keep two branches in the git repository, one is for upstream, I put everything needed to this branch request Wolfgang to review and merge; the other is master, I apply all unacceptable patches on this branch, so that user can clone it and simply build to get a more feature u-boot. The point that put all unacceptable patches to the master branch is making git-clone like as cvs/svn checkout, user don't need to do anything but only "make" the package and get the binary. Just my thoughts.
Does this make sense?
-Aubrey