Added a custodian status page to denx.de/UBoot
Dear Fellow Custodians:
With Wolfgang's blessing, I created a page on the UBoot TWiki so I could post status and ToDo information for u-boot-fdt. It is linked off the "Custodians" page (table).
<http://www.denx.de/wiki/UBoot/Custodians>
My thought is the custodian treas are a work-in-progress, so it would be good to show what the current state of progress is. I have turned the "Area/Subsystem" column entry for "u-boot-fdt" into a link to a "more info" page. I invite the other custodians to do the same, assuming that it is useful for the given custodian repository.
Best regards,
gvb
Quoted 5 lines · In message <[email protected]> you wrote:
With Wolfgang's blessing, I created a page on the UBoot TWiki so I could post status and ToDo information for u-boot-fdt. It is linked off the "Custodians" page (table).
<http://www.denx.de/wiki/UBoot/Custodians>
Thanks.
Quoted 5 lines
My thought is the custodian treas are a work-in-progress, so it would be good to show what the current state of progress is. I have turned the "Area/Subsystem" column entry for "u-boot-fdt" into a link to a "more info" page. I invite the other custodians to do the same, assuming that it is useful for the given custodian repository.
BTW: I disagree with your entry on
http://www.denx.de/wiki/UBoot/CustodianGitTrees
I think you should use branches on your local repository, but not on the custodian repo. There, I want to see no branches.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It is clear that the individual who persecutes a man, his brother, because he is not of the same opinion, is a monster. - Voltaire
Quoted 8 lines · --- Wolfgang Denk
BTW: I disagree with your entry on
http://www.denx.de/wiki/UBoot/CustodianGitTreesI think you should use branches on your local
repository, but not on
the custodian repo. There, I want to see no
branches.
Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e. code that's not intended for short-term upstream merging). Is this bad?
regards,
Ben
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 6 lines
I think you should use branches on your local
repository, but not on
the custodian repo. There, I want to see no
branches.Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e. code that's not intended for short-term upstream merging). Is this bad?
I don't know. We will have to learn all together how this works out best.
So far my impression is that git is stil very new to most of the users (and even some of the custodians) so I would like to keep things as simple as possible.
Please feel free to try out how others accept such branches. I can deal with them - just let me know exactly whre to pull from.
But please keep in mind that we just added one level of complexity to the end users by switchign from one central "official" repository to so many separate custodian trees. Adding branches to these trees adds another level of complexity, and my feeling is that this will confuse most users. But I may be wrong.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de In a survey taken several years ago, all incoming freshmen at MIT were asked if they expected to graduate in the top half of their class. Ninety-seven percent responded that they did.
Quoted 12 lines
-----Original Message-----
From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Wolfgang Denk
Sent: 05 April 2007 01:25
To: Ben Warren
Cc: u-boot-users at lists.sourceforge.net; Jerry Van Baren
Subject: Re: [U-Boot-Users] Added a custodian status page to denx.de/UBoot
Quoted 10 lines
Quoted 2 lines · In message <[email protected]> you wrote:
Quoted 2 lines
I think you should use branches on your local repository,
but not
Quoted 6 lines
Quoted 2 lines
on the custodian repo. There, I want to see no branches.
Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e.
code that's not intended for short-term upstream merging). Is this bad?
Wolfgang
Now I believe I can push branches to the u-boot-arm repo
(I was reading gu-arm as git-arm - I should use bigger fonts.....)
I was hoping to push each patch that I approved up to the u-boot-arm as a branch,
for others to test.
Then I would ask you to merge from it when testing was complete.
Then I would delete that branch when merged.....
Peter
Quoted 29 lines · Peter Pearse
Quoted 10 lines
-----Original Message-----
From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Wolfgang Denk
Sent: 05 April 2007 01:25
To: Ben Warren
Cc: u-boot-users at lists.sourceforge.net; Jerry Van Baren
Subject: Re: [U-Boot-Users] Added a custodian status page to denx.de/UBootQuoted 9 lines
Quoted 1 line · In message <[email protected]> you wrote:
Quoted 1 line
I think you should use branches on your local repository,
but not
Quoted 6 lines
Quoted 2 lines
on the custodian repo. There, I want to see no branches.
Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e.
code that's not intended for short-term upstream merging). Is this bad?Wolfgang
Now I believe I can push branches to the u-boot-arm repo(I was reading gu-arm as git-arm - I should use bigger fonts.....)
I was hoping to push each patch that I approved up to the u-boot-arm as a branch,
for others to test.
Quoted 5 lines
Then I would ask you to merge from it when testing was complete.
Then I would delete that branch when merged.....
Peter
I would like to give branches a chance. They have been supported since RCS (or before) so most people are familiar with the concept, if perhaps not the actual use. I find branches in git are very usable and extremely useful.
I've added a section describing the use and status of (the) branch(es) in my custodian repository:
<http://www.denx.de/wiki/UBoot/UBootFdtInfo>
Now I can simply reply "RTFM" (as if /that/ ever worked ;-).
gvb
Quoted 2 lines · In message <[email protected]> you wrote:
Now I believe I can push branches to the u-boot-arm repo
Yes, you can do that.
Quoted 1 line
(I was reading gu-arm as git-arm - I should use bigger fonts.....)
The "gu" prefix is just our internal market that the user ID is for a "[g]it [U]-Boot" repository.
Quoted 3 lines
I was hoping to push each patch that I approved up to the u-boot-arm as a branch,
for others to test.
I'm not sure if this is actually a good idea. It may quickly create a mess of branches.
Quoted 1 line
Then I would ask you to merge from it when testing was complete.
Please don;t. I want *you* to perform the merging, and when this was successful, to send me a pull request. This way, I can always pull from your master branch and don;t have to care if there are hundrets of branches in your tree and what is for what.
Quoted 1 line
Then I would delete that branch when merged.....
You cannot delete anything in a git repository. Onc created, i remains there forever.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Do not simplify the design of a program if a way can be found to make it complex and wonderful.
Quoted 5 lines · In message <[email protected]> you wrote:
I would like to give branches a chance. They have been supported since RCS (or before) so most people are familiar with the concept, if perhaps not the actual use. I find branches in git are very usable and extremely useful.
Please don't hesitate to go on. You are right, no other SCM system I know makes branch handling so easy. On the other hand, please keep me out of this - such branches shall be your own playground as custodians. When you send me a pull request, I always want to pull from the master branch. I don't even want to know if there are any other branches, or how many of them, or what for. So you do the merging, please, not me.
Quoted 4 lines
I've added a section describing the use and status of (the) branch(es) in my custodian repository:
<http://www.denx.de/wiki/UBoot/UBootFdtInfo>
Now I can simply reply "RTFM" (as if /that/ ever worked ;-).
It works, if you do it.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If you hear an onion ring, answer it.
Quoted 25 lines · Wolfgang Denk
Quoted 2 lines · In message <[email protected]> you wrote:
Now I believe I can push branches to the u-boot-arm repo
Yes, you can do that.
Quoted 1 line
(I was reading gu-arm as git-arm - I should use bigger fonts.....)
The "gu" prefix is just our internal market that the user ID is for a "[g]it [U]-Boot" repository.
Quoted 3 lines
I was hoping to push each patch that I approved up to the u-boot-arm as a branch,
for others to test.I'm not sure if this is actually a good idea. It may quickly create a mess of branches.
Quoted 1 line
Then I would ask you to merge from it when testing was complete.
Please don;t. I want *you* to perform the merging, and when this was successful, to send me a pull request. This way, I can always pull from your master branch and don;t have to care if there are hundrets of branches in your tree and what is for what.
Quoted 8 lines
Quoted 1 line
Then I would delete that branch when merged.....
You cannot delete anything in a git repository. Onc created, i remains there forever.
Best regards,
Wolfgang Denk
I have not looked in the repository to see what it actually does, but "git branch -d" deletes merged branches (it refuses to delete unmerged branches) and "git branch -D" deletes unmerged branches. I presume this does not leave much detritus.
If we use branches:
1) 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
2) Must be kept clean - delete ones no longer useful
3) 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).
On the Custodian page
<http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Pulling_changes_from_the_master>
I took a crack at the process to do (3) - I don't believe my recipe is correct yet. Maybe I'll get the right recipe on my next change or maybe a git wizard will update it. (I think the best approach is to create a temporary merge branch in your local repo, pull the latest "master" into it, pull your "to-be-pulled" branch into it, resolve any problems, and then delete the temp merge branch.)
gvb
Quoted 61 lines · Jerry Van Baren
Quoted 21 lines · Wolfgang Denk
Quoted 2 lines · In message <[email protected]> you wrote:
Now I believe I can push branches to the u-boot-arm repo
Yes, you can do that.
Quoted 1 line
(I was reading gu-arm as git-arm - I should use bigger fonts.....)
The "gu" prefix is just our internal market that the user ID is for a "[g]it [U]-Boot" repository.
Quoted 3 lines
I was hoping to push each patch that I approved up to the u-boot-arm as a branch,
for others to test.I'm not sure if this is actually a good idea. It may quickly create a mess of branches.
Quoted 1 line
Then I would ask you to merge from it when testing was complete.
Please don;t. I want *you* to perform the merging, and when this was successful, to send me a pull request. This way, I can always pull from your master branch and don;t have to care if there are hundrets of branches in your tree and what is for what.
Quoted 7 lines
Quoted 1 line
Then I would delete that branch when merged.....
You cannot delete anything in a git repository. Onc created, i remains there forever.
Best regards,
Wolfgang Denk
I have not looked in the repository to see what it actually does, but "git branch -d" deletes merged branches (it refuses to delete unmerged branches) and "git branch -D" deletes unmerged branches. I presume this does not leave much detritus.
If we use branches:
1) 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
2) Must be kept clean - delete ones no longer useful
3) 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
7cd5da0fe877e7171a4cdd44880bce783132871atoaea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit of a paper tiger).On the Custodian page
<http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Pulling_changes_from_the_master>
I took a crack at the process to do (3) - I don't believe my recipe is correct yet. Maybe I'll get the right recipe on my next change or maybe a git wizard will update it. (I think the best approach is to create a temporary merge branch in your local repo, pull the latest "master" into it, pull your "to-be-pulled" branch into it, resolve any problems, and then delete the temp merge branch.)
Quoted 1 line
gvb
OK, I thought about it for 30 seconds and I think this is a good recipe (still to be proofed out):
<http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t>
especially the section "BEFORE Requesting a Pull"
Best regards,
gvb
Jerry,
Quoted 9 lines · Jerry Van Baren
If we use branches:
1) 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
2) Must be kept clean - delete ones no longer useful
3) 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;-)
Quoted 7 lines
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
7cd5da0fe877e7171a4cdd44880bce783132871atoaea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" 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...
Thoughts?
Ben
Quoted 39 lines · Ben Warren
Jerry,
Quoted 9 lines · Jerry Van Baren
If we use branches:
1) 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
2) Must be kept clean - delete ones no longer useful
3) 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;-)Quoted 7 lines
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
7cd5da0fe877e7171a4cdd44880bce783132871atoaea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" 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-wrappedinitialize()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.
Quoted 4 lines
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
Quoted 39 lines · Ben Warren
Jerry,
Quoted 9 lines · Jerry Van Baren
If we use branches:
1) 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
2) Must be kept clean - delete ones no longer useful
3) 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;-)Quoted 7 lines
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
7cd5da0fe877e7171a4cdd44880bce783132871atoaea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" 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-wrappedinitialize()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.
Quoted 7 lines
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...
Thoughts?
Ben
I think we are fundamentally in agreement, but my point of view is that a custodian repository is, by definition, (fairly) radical changes. My concern is that, if we restrict ourselves to only the mainline of the custodian repository, it is very difficult to have more than one change "in flight" and it makes it nearly impossible to publish "work in progress" that isn't ready to be pulled yet. Wolfgang has been very responsive (have I said THANKS! yet?) so time of flight for pull requests has not been a problem... yet.
Best regards,
gvb
Quoted 3 lines · In message <[email protected]> you…
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.
Sounds like an oxymoron to me. If they are usefulk to many people, then why are they "not common enough to be committed into mainline"?
Quoted 6 lines
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.
OK, just do it exactly the other way round: master is for upstream, and you can have a "testing" or "cutsom" or whatever branch for your local stuff.
But please note that the main task of the custodoian is to help merge code into mainline, *not* to nurture code split.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Pull the wool over your own eyes!" - J.R. "Bob" Dobbs
Quoted 7 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you…
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.
Sounds like an oxymoron to me. If they are usefulk to many people, then why are they "not common enough to be committed into mainline"?
-- The patch like Mike posted here, clobber the u-boot style, but make u-boot more portable.
-------------------------------------------------
Quoted 9 lines
we've moved
TEXT_BASEout of the build system for Blackfin and into the config header so that when porting to a new board, users dont need to set both theCFG_MONITOR_BASEandTEXT_BASEto the same value in two remotely different filesfor u-boot general though, i'd like to apply the attached patch that simply says only utilize
TEXT_BASEin global common files if it is set ... that way everyone else can continue to useTEXT_BASEin their board specific .mk files while in Blackfin, we can simply unset it
------------------------------------------------
-- The patch like the SPI patch I posted here, need time to be processed, but because it's a bug, u-boot can't work properly without it.
-- The patch like ATA patch in my hand, we enabled the TRUE IDE feature for CF flash card access, but the configuration of the hardware we are using need to clobber the common file ./include/ata.h,
because the ata register map is not in a common way.
-- etc.
Quoted 11 lines
Quoted 7 lines
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.OK, just do it exactly the other way round: master is for upstream, and you can have a "testing" or "cutsom" or whatever branch for your local stuff.
That means users have to learn more than one git command. if master for the users, they just have to git-clone and build; if another branch for the users, they have to clone and create branch. But yes, it's not a big deal, just my thoughts.
Best Regards,
-Aubrey
Quoted 9 lines · Aubrey Li
Quoted 8 lines · Wolfgang Denk
In message <[email protected]> you wrote
Quoted 6 lines
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.
Quoted 8 lines
Quoted 3 lines
OK, just do it exactly the other way round: master is for upstream, and you can have a "testing" or "cutsom" or whatever branch for your local stuff.
That means users have to learn more than one git command. if master for the users, they just have to git-clone and build; if another branch for the users, they have to clone and create branch. But yes, it's not a big deal, just my thoughts.
I agree with Aubrey. Wolfgang, I imagine you know a lot better how branches work than most users, so I think it makes most sense to keep "needs more testing" stuff in the master branch to maximize the amount of testing. If pull requests are on the form
git://repository/... for-wolfgang
i.e. the repository URI and the branch name all on a single line, all you have to do is triple-click it and paste it into the terminal after "git pull".
Besides, this allows the custodians to reorder and combine patches to keep the revision history clean, and rebase it against the latest upstream head before sending a pull request. Doing such things on the master branch will confuse the hell out of many users pulling from it.
Haavard