[U-Boot] ARM Workflow: rebase on ARM repositories

[U-Boot] ARM Workflow: rebase on ARM repositories

[Stefano Babic]

Hi all ARM Custodians,

I was thinking about the way we are usual to manage our trees. This
comes because I know about issues from users who set their development
on ARM-repositories.

One of them uses u-boot-imx for his development, and of course after I
rebased my tree he got into trouble, due to using a commit that does not
exist anymore.
Nevertheless there are boards, where the official documentation explain
how to set patches on bases of u-boot-arm. For example,

	http://www.ti.com/tool/tmdsevm3530

Detlev discovers that the official documentation refers directly to
commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
rebase this commit does not exist anymore.

Of course, we can really say that setting a development on a ARM
repository instead of main repository is not the best ;-). But we know
that sometimes setting on a partial repository is the best because some
patches that are strictly required are already merged. And I do not know
if we can say that our trees are "private" or "development" only: they
are published, and available for everybody.

Albert has described the way we are currently using in
http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
very well and it is the way we follow, and we usually rebase our tree
after u-boot-arm is merged by Wolgang in mainline. I want to discuss
here if we really need it and if this is the correct way to do.

In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
rebases, and I had never had the problem that my tree diverges when I
update my kernel's trees from a mainatiner tree. However, this happens
continuosly for the users of u-boot-imx. The way we are following  can
be seen in the linux-next trees, not in the main trees.

The worst thing I think is that we lose the history of our tree, and the
behavior can be different. Rebased patches can be different, and testing
done until the rebase can be worthless and should be (theoretically)
done again. Testers can say they have successfully test a patch, but it
was on a pre-rebased tree. A tested-by in a rebased tree can be worthless.

My big question is if we should not to come back using "git pull" to
downstream mainline from Wolfgang's tree, instead of continuos rebase. I
know that we switched to rebase to avoid a lot of "git merge commits",
but maybe this is not so bad as rebasing.

What is your opinion ?

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] ARM Workflow: rebase on ARM repositories

[Stefan Roese]

Hi Stefano,

On 09/03/2012 02:36 PM, Stefano Babic wrote:
> I was thinking about the way we are usual to manage our trees. This
> comes because I know about issues from users who set their development
> on ARM-repositories.
> 
> One of them uses u-boot-imx for his development, and of course after I
> rebased my tree he got into trouble, due to using a commit that does not
> exist anymore.
> Nevertheless there are boards, where the official documentation explain
> how to set patches on bases of u-boot-arm. For example,
> 
> 	http://www.ti.com/tool/tmdsevm3530
> 
> Detlev discovers that the official documentation refers directly to
> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
> rebase this commit does not exist anymore.
> 
> Of course, we can really say that setting a development on a ARM
> repository instead of main repository is not the best ;-). But we know
> that sometimes setting on a partial repository is the best because some
> patches that are strictly required are already merged. And I do not know
> if we can say that our trees are "private" or "development" only: they
> are published, and available for everybody.
> 
> Albert has described the way we are currently using in
> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
> very well and it is the way we follow, and we usually rebase our tree
> after u-boot-arm is merged by Wolgang in mainline. I want to discuss
> here if we really need it and if this is the correct way to do.
> 
> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
> rebases, and I had never had the problem that my tree diverges when I
> update my kernel's trees from a mainatiner tree. However, this happens
> continuosly for the users of u-boot-imx. The way we are following  can
> be seen in the linux-next trees, not in the main trees.
> 
> The worst thing I think is that we lose the history of our tree, and the
> behavior can be different. Rebased patches can be different, and testing
> done until the rebase can be worthless and should be (theoretically)
> done again. Testers can say they have successfully test a patch, but it
> was on a pre-rebased tree. A tested-by in a rebased tree can be worthless.
> 
> My big question is if we should not to come back using "git pull" to
> downstream mainline from Wolfgang's tree, instead of continuos rebase. I
> know that we switched to rebase to avoid a lot of "git merge commits",
> but maybe this is not so bad as rebasing.
> 
> What is your opinion ?

I'm quite astonished about this rebasing you mention here. I'm not an
RAM custodian, so thats probably why I was not aware of it. But I do
manage 3 U-Boot custodian repositories (non-ARM). And I can't remember
that I had to rebase my custodian repositories ever. My workflow is the
one you describe with "git pull" based on Wolfgangs mainline tree. And
this definitely should be preferred over rebasing.

Aren't those merge problems solvable without rebasing in the ARM trees?

Thanks,
Stefan

[U-Boot] ARM Workflow: rebase on ARM repositories

[Stefano Babic]

On 03/09/2012 15:13, Stefan Roese wrote:
> Hi Stefano,
> 
> On 09/03/2012 02:36 PM, Stefano Babic wrote:
>> I was thinking about the way we are usual to manage our trees. This
>> comes because I know about issues from users who set their development
>> on ARM-repositories.
>>
>> One of them uses u-boot-imx for his development, and of course after I
>> rebased my tree he got into trouble, due to using a commit that does not
>> exist anymore.
>> Nevertheless there are boards, where the official documentation explain
>> how to set patches on bases of u-boot-arm. For example,
>>
>> 	http://www.ti.com/tool/tmdsevm3530
>>
>> Detlev discovers that the official documentation refers directly to
>> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
>> rebase this commit does not exist anymore.
>>
>> Of course, we can really say that setting a development on a ARM
>> repository instead of main repository is not the best ;-). But we know
>> that sometimes setting on a partial repository is the best because some
>> patches that are strictly required are already merged. And I do not know
>> if we can say that our trees are "private" or "development" only: they
>> are published, and available for everybody.
>>
>> Albert has described the way we are currently using in
>> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
>> very well and it is the way we follow, and we usually rebase our tree
>> after u-boot-arm is merged by Wolgang in mainline. I want to discuss
>> here if we really need it and if this is the correct way to do.
>>
>> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
>> rebases, and I had never had the problem that my tree diverges when I
>> update my kernel's trees from a mainatiner tree. However, this happens
>> continuosly for the users of u-boot-imx. The way we are following  can
>> be seen in the linux-next trees, not in the main trees.
>>
>> The worst thing I think is that we lose the history of our tree, and the
>> behavior can be different. Rebased patches can be different, and testing
>> done until the rebase can be worthless and should be (theoretically)
>> done again. Testers can say they have successfully test a patch, but it
>> was on a pre-rebased tree. A tested-by in a rebased tree can be worthless.
>>
>> My big question is if we should not to come back using "git pull" to
>> downstream mainline from Wolfgang's tree, instead of continuos rebase. I
>> know that we switched to rebase to avoid a lot of "git merge commits",
>> but maybe this is not so bad as rebasing.
>>
>> What is your opinion ?
> 
> I'm quite astonished about this rebasing you mention here. I'm not an
> RAM custodian, so thats probably why I was not aware of it. But I do
> manage 3 U-Boot custodian repositories (non-ARM). And I can't remember
> that I had to rebase my custodian repositories ever. My workflow is the
> one you describe with "git pull" based on Wolfgangs mainline tree. And
> this definitely should be preferred over rebasing.
> 
> Aren't those merge problems solvable without rebasing in the ARM trees?

This is what is done in Linux - I wonder that we do differently.

Cheers,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] ARM Workflow: rebase on ARM repositories

[Albert ARIBAUD]

Hi Stefano,

On Mon, 03 Sep 2012 14:36:31 +0200, Stefano Babic <sbabic@denx.de>
wrote:

> Hi all ARM Custodians,
> 
> I was thinking about the way we are usual to manage our trees. This
> comes because I know about issues from users who set their development
> on ARM-repositories.
> 
> One of them uses u-boot-imx for his development, and of course after I
> rebased my tree he got into trouble, due to using a commit that does
> not exist anymore.

You mean a commit ID that does not exist any more, right?

> Nevertheless there are boards, where the official documentation
> explain how to set patches on bases of u-boot-arm. For example,
> 
> 	http://www.ti.com/tool/tmdsevm3530

I haven't found where in the page a reference to u-boot-arm was made.
Can you clarify this?

> Detlev discovers that the official documentation refers directly to
> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
> rebase this commit does not exist anymore.

That can happen indeed. I *do* hope that the commit was also described
by its (invariant) commit summary.

> Of course, we can really say that setting a development on a ARM
> repository instead of main repository is not the best ;-). But we know
> that sometimes setting on a partial repository is the best because
> some patches that are strictly required are already merged. And I do
> not know if we can say that our trees are "private" or "development"
> only: they are published, and available for everybody.

But they are not official. The official release is u-boot/master.

> Albert has described the way we are currently using in
> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you
> konow very well and it is the way we follow, and we usually rebase
> our tree after u-boot-arm is merged by Wolgang in mainline. I want to
> discuss here if we really need it and if this is the correct way to
> do.
> 
> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
> rebases, and I had never had the problem that my tree diverges when I
> update my kernel's trees from a mainatiner tree. However, this happens
> continuosly for the users of u-boot-imx. The way we are following  can
> be seen in the linux-next trees, not in the main trees.
> 
> The worst thing I think is that we lose the history of our tree, and
> the behavior can be different. Rebased patches can be different, and
> testing done until the rebase can be worthless and should be
> (theoretically) done again. Testers can say they have successfully
> test a patch, but it was on a pre-rebased tree. A tested-by in a
> rebased tree can be worthless.

Indeed, but so can it be when the branch is pulled rather than rebased
and fast-forwarded, I believe.

> My big question is if we should not to come back using "git pull" to
> downstream mainline from Wolfgang's tree, instead of continuos
> rebase. I know that we switched to rebase to avoid a lot of "git
> merge commits", but maybe this is not so bad as rebasing.
> 
> What is your opinion ?

This reference;

<http://programmers.stackexchange.com/questions/72632/are-there-any-flaws-with-this-git-branching-model>

(see the detailed answer re merging vs rebasing, and the answer to this
answer) gives us two additional pieces of info:

a) we are not the only project where the opposition between merging and
branching strategies is considered; :)

b) merging requires testing just like rebasing does, which is kind of
evident as for a given pair of branches, both methods yield, or should
yield, the same semantic semantic union of the branches).

My preference goes to rebasing rather than merging because in a
rebasing strategy, each commit in the main branch is a single,
understandable, purposeful change, whereas with merging, if the commit
is a merge, it can be a complete set of pervasive changes which are not
readily identifiable and may serve lots of purposes.

OTOH, we all can see Wolfgang sometimes performing pulls by merging,
so he might have a different view on this.

> Regards,
> Stefano

Amicalement,
-- 
Albert.

[U-Boot] ARM Workflow: rebase on ARM repositories

[Wolfgang Denk]

Dear Stefano,

In message <5044A44F.2050204@denx.de> you wrote:
> 
> One of them uses u-boot-imx for his development, and of course after I
> rebased my tree he got into trouble, due to using a commit that does not
> exist anymore.

Thanks for bringing up this topic.

> Albert has described the way we are currently using in
> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
> very well and it is the way we follow, and we usually rebase our tree
> after u-boot-arm is merged by Wolgang in mainline. I want to discuss
> here if we really need it and if this is the correct way to do.

I think it is wrong to rebase any tree for which it is not very
clearly and lodly announced that this tree gets rebased on a more or
less regular base. linux-next is such an example - we allknow it gets
rebased frequently, so we can arrange with it (though I have to admit
that I dn't like it, and that I've been bitten myself more than once
by this).

For u-boot-*, most users I know are not aware of any rebasing policy.

> My big question is if we should not to come back using "git pull" to
> downstream mainline from Wolfgang's tree, instead of continuos rebase. I
> know that we switched to rebase to avoid a lot of "git merge commits",
> but maybe this is not so bad as rebasing.

I would prefer to have at least rebase-free "master" branches in all
custodian repositories.  It is perfectly OK to have working branches,
and to rebase these as work progresses.  But for the master branches,
a rebase should be more or less tabu.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We are Microsoft. Unix is irrelevant. Openness is futile.  Prepare to
be assimilated.

[U-Boot] ARM Workflow: rebase on ARM repositories

[Wolfgang Denk]

Dear Albert,

In message <20120903200244.2ddad7d4@lilith> you wrote:
> 
> > One of them uses u-boot-imx for his development, and of course after I
> > rebased my tree he got into trouble, due to using a commit that does
> > not exist anymore.
> 
> You mean a commit ID that does not exist any more, right?

Yes, and this is the same.

> > Detlev discovers that the official documentation refers directly to
> > commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
> > rebase this commit does not exist anymore.
> 
> That can happen indeed. I *do* hope that the commit was also described
> by its (invariant) commit summary.

I seriously dislike this for the master branch.

> > Of course, we can really say that setting a development on a ARM
> > repository instead of main repository is not the best ;-). But we know
> > that sometimes setting on a partial repository is the best because
> > some patches that are strictly required are already merged. And I do
> > not know if we can say that our trees are "private" or "development"
> > only: they are published, and available for everybody.
> 
> But they are not official. The official release is u-boot/master.

Define "official".  Wepublicly announce the existence of ht ecustodian
repositories, and in many cases when you need current code the way to
the custodian repo is the most direct one.

> a) we are not the only project where the opposition between merging and
> branching strategies is considered; :)
> 
> b) merging requires testing just like rebasing does, which is kind of
> evident as for a given pair of branches, both methods yield, or should
> yield, the same semantic semantic union of the branches).

But merging keeps all the history in place, i. e. you can always refer
to any specific "old" commit ID, and be sure that it is what you
really refer to because it is secured by cryptographically strong
checksums.

By rebasing, you lose all this history.  Even if you manage to find a
commit that "looks" the same judging from the commit message etc., you
have no guarantee that it's really the same code.

> My preference goes to rebasing rather than merging because in a
> rebasing strategy, each commit in the main branch is a single,
> understandable, purposeful change, whereas with merging, if the commit
> is a merge, it can be a complete set of pervasive changes which are not
> readily identifiable and may serve lots of purposes.

Please feel free to do this in working branches.  But I would really
appreciate it if we could stop rebasing any "master" branches.

> OTOH, we all can see Wolfgang sometimes performing pulls by merging,
> so he might have a different view on this.

Not sometimes.  I _always_ use "git pull". 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In Nature there are neither rewards nor punishments, there are conse-
quences.                                            -- R.G. Ingersoll

[U-Boot] ARM Workflow: rebase on ARM repositories

[Albert ARIBAUD]

Hi Wolfgang,

On Mon, 03 Sep 2012 21:13:28 +0200, Wolfgang Denk <wd@denx.de> wrote:

> Dear Albert,
> 
> In message <20120903200244.2ddad7d4@lilith> you wrote:
> > 
> > > One of them uses u-boot-imx for his development, and of course
> > > after I rebased my tree he got into trouble, due to using a
> > > commit that does not exist anymore.
> > 
> > You mean a commit ID that does not exist any more, right?
> 
> Yes, and this is the same.
> 
> > > Detlev discovers that the official documentation refers directly
> > > to commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm.
> > > After a rebase this commit does not exist anymore.
> > 
> > That can happen indeed. I *do* hope that the commit was also
> > described by its (invariant) commit summary.
> 
> I seriously dislike this for the master branch.

Stefano's reference was about u-boot-arm specifically, and so was my
comment to it. I do agree with you re: the U-Boot master branch (see
below for additional notes)
 
> > > Of course, we can really say that setting a development on a ARM
> > > repository instead of main repository is not the best ;-). But we
> > > know that sometimes setting on a partial repository is the best
> > > because some patches that are strictly required are already
> > > merged. And I do not know if we can say that our trees are
> > > "private" or "development" only: they are published, and
> > > available for everybody.
> > 
> > But they are not official. The official release is u-boot/master.
> 
> Define "official".  Wepublicly announce the existence of ht ecustodian
> repositories, and in many cases when you need current code the way to
> the custodian repo is the most direct one.

I consider the official U-Boot to be the one which is used for releases,
and bears labels denoting these. I do not consider official the
architecture trees because -- as per the current rules -- their
custodian may rebase them before a pull request, thus cause the very
trouble Stefano is talking about.

> > a) we are not the only project where the opposition between merging
> > and branching strategies is considered; :)
> > 
> > b) merging requires testing just like rebasing does, which is kind
> > of evident as for a given pair of branches, both methods yield, or
> > should yield, the same semantic semantic union of the branches).
> 
> But merging keeps all the history in place, i. e. you can always refer
> to any specific "old" commit ID, and be sure that it is what you
> really refer to because it is secured by cryptographically strong
> checksums.
> 
> By rebasing, you lose all this history.  Even if you manage to find a
> commit that "looks" the same judging from the commit message etc., you
> have no guarantee that it's really the same code.

Correct.

> > My preference goes to rebasing rather than merging because in a
> > rebasing strategy, each commit in the main branch is a single,
> > understandable, purposeful change, whereas with merging, if the
> > commit is a merge, it can be a complete set of pervasive changes
> > which are not readily identifiable and may serve lots of purposes.
> 
> Please feel free to do this in working branches.  But I would really
> appreciate it if we could stop rebasing any "master" branches.

I'll be fine either way. Just note that this policy is at odds with the
documentation at http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees
which suggests rebasing, not merging, masters; the doc should be
changed to match the policy.

> > OTOH, we all can see Wolfgang sometimes performing pulls by merging,
> > so he might have a different view on this.
> 
> Not sometimes.  I _always_ use "git pull". 

I guess the occasions where I did not see a merge was when it was
trivialized into a fast-forward, then.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] ARM Workflow: rebase on ARM repositories

[Wolfgang Denk]

Dear Albert,

In message <20120903214729.4f3949e7@lilith> you wrote:
> 
> > I seriously dislike this for the master branch.
> 
> Stefano's reference was about u-boot-arm specifically, and so was my
> comment to it. I do agree with you re: the U-Boot master branch (see
> below for additional notes)

You misunderstand me.  I was referring to the "master" branch of the
"u-boot-arm" repository.  This, like all "master" brnaches in all
custodian repositories, should _never_ get rebased.

> I consider the official U-Boot to be the one which is used for releases,
> and bears labels denoting these. I do not consider official the
> architecture trees because -- as per the current rules -- their
> custodian may rebase them before a pull request, thus cause the very
> trouble Stefano is talking about.

We're discussing to change the current rules, as they make no sense to
me, and to a few others.  And a number of users have been bitten by
these.

I repeat:  rebasing is of for any working branches.  But the master
branches in any of the custodian repos should not get rebased.

> I'll be fine either way. Just note that this policy is at odds with the
> documentation at http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees
> which suggests rebasing, not merging, masters; the doc should be
> changed to match the policy.

Definitely.

> > Not sometimes.  I _always_ use "git pull". 
> 
> I guess the occasions where I did not see a merge was when it was
> trivialized into a fast-forward, then.

Correct.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be awake is to be alive.        - Henry David Thoreau, in "Walden"

[U-Boot] ARM Workflow: rebase on ARM repositories

[Stefano Babic]

Am 03/09/2012 20:02, schrieb Albert ARIBAUD:
> Hi Stefano,
> 

Hi Albert,


>> One of them uses u-boot-imx for his development, and of course after I
>> rebased my tree he got into trouble, due to using a commit that does
>> not exist anymore.
> 
> You mean a commit ID that does not exist any more, right?

Right.

> 
>> Nevertheless there are boards, where the official documentation
>> explain how to set patches on bases of u-boot-arm. For example,
>>
>> 	http://www.ti.com/tool/tmdsevm3530
> 
> I haven't found where in the page a reference to u-boot-arm was made.
> Can you clarify this?

I have not found this issue myself - Detlev discovers that in the
documentation for the bootloader (I think inside the SDK that can be
download following the link in that page) there is an a reference to a
commit-id in u-boot-arm.

> 
>> Of course, we can really say that setting a development on a ARM
>> repository instead of main repository is not the best ;-). But we know
>> that sometimes setting on a partial repository is the best because
>> some patches that are strictly required are already merged. And I do
>> not know if we can say that our trees are "private" or "development"
>> only: they are published, and available for everybody.
> 
> But they are not official. The official release is u-boot/master.

This is a point - I have also considered that the architecture trees are
unofficial, and users should clone their tree from Wolfgang's tree.

Nevertheless, all these tree are published, and nobody says that they
cannot be used. And they look like as the architecture trees for linux
(linux-omap, linux-imx,...). They also are not rebased and it is not
unusual to get the last status for an architecture from one of these trees.

> 
> This reference;
> 
> <http://programmers.stackexchange.com/questions/72632/are-there-any-flaws-with-this-git-branching-model>
> 
> (see the detailed answer re merging vs rebasing, and the answer to this
> answer) gives us two additional pieces of info:
> 
> a) we are not the only project where the opposition between merging and
> branching strategies is considered; :)

Right, this is true.

> b) merging requires testing just like rebasing does, which is kind of
> evident as for a given pair of branches, both methods yield, or should
> yield, the same semantic semantic union of the branches).
> 

To extend this with the behavior in Linux, this is the link of Jonathan
Corbet's article on lvm:

 http://lwn.net/Articles/328436/

So there are in both cases advantages and drawbacks - the issue is which
is the more suitable for our project. I tend to avoid rebasing due to
the fact that I should not consider u-boot-imx my private and hidden
branch, but a public repository.

> My preference goes to rebasing rather than merging because in a
> rebasing strategy, each commit in the main branch is a single,
> understandable, purposeful change, whereas with merging, if the commit
> is a merge, it can be a complete set of pervasive changes which are not
> readily identifiable and may serve lots of purposes.
> 
> OTOH, we all can see Wolfgang sometimes performing pulls by merging,
> so he might have a different view on this.

Of course ;-)


Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] ARM Workflow: rebase on ARM repositories

[Albert ARIBAUD]

Hi Stefano,

On Tue, 04 Sep 2012 11:37:52 +0200, Stefano Babic <sbabic@denx.de>
wrote:

> > OTOH, we all can see Wolfgang sometimes performing pulls by merging,
> > so he might have a different view on this.
> 
> Of course ;-)

And so he has expressed, before your reply actually, and clearly
expressed a preference for merging rather than rebasing.

Next step - considering I've been the only one apparently to express
adissenting opinion - is thus to change the Denx Wiki documentation
about custodian trees so that it matches our policy.

> Regards,
> Stefano

Amicalement,
-- 
Albert.

[U-Boot] ARM Workflow: rebase on ARM repositories

[Stephen Warren]

On 09/04/2012 03:37 AM, Stefano Babic wrote:
> Am 03/09/2012 20:02, schrieb Albert ARIBAUD:
>> Hi Stefano,
>>
> 
> Hi Albert,
> 
> 
>>> One of them uses u-boot-imx for his development, and of course after I
>>> rebased my tree he got into trouble, due to using a commit that does
>>> not exist anymore.
>>
>> You mean a commit ID that does not exist any more, right?
> 
> Right.
> 
>>
>>> Nevertheless there are boards, where the official documentation
>>> explain how to set patches on bases of u-boot-arm. For example,
>>>
>>> 	http://www.ti.com/tool/tmdsevm3530
>>
>> I haven't found where in the page a reference to u-boot-arm was made.
>> Can you clarify this?
> 
> I have not found this issue myself - Detlev discovers that in the
> documentation for the bootloader (I think inside the SDK that can be
> download following the link in that page) there is an a reference to a
> commit-id in u-boot-arm.
> 
>>
>>> Of course, we can really say that setting a development on a ARM
>>> repository instead of main repository is not the best ;-). But we know
>>> that sometimes setting on a partial repository is the best because
>>> some patches that are strictly required are already merged. And I do
>>> not know if we can say that our trees are "private" or "development"
>>> only: they are published, and available for everybody.
>>
>> But they are not official. The official release is u-boot/master.
> 
> This is a point - I have also considered that the architecture trees are
> unofficial, and users should clone their tree from Wolfgang's tree.
> 
> Nevertheless, all these tree are published, and nobody says that they
> cannot be used. And they look like as the architecture trees for linux
> (linux-omap, linux-imx,...). They also are not rebased and it is not
> unusual to get the last status for an architecture from one of these trees.

We have this issue on Tegra a lot too; Tegra is pretty new, and so
anyone running U-Boot on Tegra typically uses the Tegra repo, not even
the ARM repo.

If we're voting, I personally fully support a move to a pure merge-based
workflow (although note that I'm not a maintainer of any part of U-Boot,
just a contributor to many Tegra boards).