[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Jerry Van Baren]

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Wolfgang Denk]

In message <46141237.9060703@smiths-aerospace.com> 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.

> 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

-- 
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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Ben Warren]

--- Wolfgang Denk <wd@denx.de> wrote:


> 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.
> 
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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Wolfgang Denk]

In message <891383.24029.qm@web313.biz.mail.mud.yahoo.com> you wrote:
> 
> > 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

-- 
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.

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Peter Pearse]

 

> -----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
> 
> In message <891383.24029.qm@web313.biz.mail.mud.yahoo.com> you wrote:
> > 
> > > 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?

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Jerry Van Baren]

Peter Pearse wrote:
>> -----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
>>
>> In message <891383.24029.qm@web313.biz.mail.mud.yahoo.com> you wrote:
>>>> 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?
> 
> 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

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Wolfgang Denk]

In message <000201c7776d$fde43300$821ba8c0@Emea.Arm.com> you wrote:
>  
> 	Now I believe I can push branches to the u-boot-arm repo 

Yes, you can do that.

> (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.

> 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.

> 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.

> 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

-- 
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.

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Wolfgang Denk]

In message <4614E885.6090702@smiths-aerospace.com> 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.

> 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

-- 
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.

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <000201c7776d$fde43300$821ba8c0@Emea.Arm.com> you wrote:
>>  
>> 	Now I believe I can push branches to the u-boot-arm repo 
> 
> Yes, you can do that.
> 
>> (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.
> 
>> 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.
> 
>> 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.
> 
>> 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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Jerry Van Baren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> In message <000201c7776d$fde43300$821ba8c0@Emea.Arm.com> you wrote:
>>>  
>>> 	Now I believe I can push branches to the u-boot-arm repo 
>> Yes, you can do that.
>>
>>> (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.
>>
>>> 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.
>>
>>> 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.
>>
>>> 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

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Ben Warren]

Jerry,

On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:

> 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).

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Aubrey Li]

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:
> > 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).
>
> 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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Jerry Van Baren]

Ben Warren wrote:
> Jerry,
> 
> On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:
> 
>> 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).
> 
> 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

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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Wolfgang Denk]

In message <27d85ee10704050821j19a6bbd8j19e820b8ee47727d@mail.gmail.com> you wrote:
>
> 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"?

> 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

-- 
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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Aubrey Li]

On 4/6/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <27d85ee10704050821j19a6bbd8j19e820b8ee47727d@mail.gmail.com> you wrote:
> >
> > 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.
-------------------------------------------------
>we've moved TEXT_BASE out 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 the
>CFG_MONITOR_BASE and TEXT_BASE to the same value in two remotely different
>files
>
>for u-boot general though, i'd like to apply the attached patch that simply
>says only utilize TEXT_BASE in global common files if it is set ... that way
>everyone else can continue to use TEXT_BASE in 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.

>
> > 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

[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Haavard Skinnemoen]

On 4/6/07, Aubrey Li <aubrey.adi@gmail.com> wrote:
> On 4/6/07, Wolfgang Denk <wd@denx.de> wrote:
> > In message <27d85ee10704050821j19a6bbd8j19e820b8ee47727d@mail.gmail.com> you wrote
> > > 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.

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