FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 04-13-2011, 02:51 PM
Bryan Wu
 
Default : 2.6.38.2 based updates

Tim,

I've got latest updates from Sebastien Jan and Andy Green
Please find the branch here:
git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4

It's based on latest 2.8.38.2 Linaro release and it is also contains
some updates since previous rebasing:
* config updates to fix some booting issues like oops and warnings
* fixed a tracing conflict due LTTng merger in Linaro kernel
* Rebased to 2.6.38.2 based Linaro kernel release
* Updates WLAN/BT/FM/Audio supporting from Andy Green and Sebastien Jan
(u0 tag of for-ubuntu branch in Andy's tree)
* Rebased to Ubuntu master branch from 2.6.38-7.38 to 2.6.38-8.40

I test it on my Panda boards, so far it boots fine without i2c timeout
and regulator warnings:
http://pastebin.ubuntu.com/593569/

Please find my prebuilt binary kernel package here:
http://people.canonical.com/~roc/kernel/ti-omap4-pre1208.11/

Thanks,
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer * *+86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd. * * *www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-13-2011, 03:32 PM
Tim Gardner
 
Default : 2.6.38.2 based updates

On 04/13/2011 07:51 AM, Bryan Wu wrote:

git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4


I presume that you're done rebasing against anything other then Natty
master? So, it needs to be able to do that cleanly and without conflict.
I just tried your branch against Ubuntu-2.6.38-8.42 and it failed.


rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-13-2011, 04:47 PM
Bryan Wu
 
Default : 2.6.38.2 based updates

On Wed, Apr 13, 2011 at 8:32 AM, Tim Gardner <tim.gardner@canonical.com> wrote:
> On 04/13/2011 07:51 AM, Bryan Wu wrote:
>>
>> git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4
>
> I presume that you're done rebasing against anything other then Natty
> master? So, it needs to be able to do that cleanly and without conflict. I
> just tried your branch against Ubuntu-2.6.38-8.42 and it failed.
>

Because the Linaro kernel is kind of merging 2.6.38.2 patches instead
of rebasing, I also got rebasing issue before. Currently, in my tree:

Linaro 2.6.38.2 from npitre (base) + Patches from Sebjan and Andy
Green + Our Ubuntu Delta patches (same from master) + ti-omap4 branch
specific patches.

So I just added patches from 2.6.38-8.41 and -8.42 on top of our
Ubuntu Delta patches, then rebase ti-omap4 branch patches on it again.

Please find the branch here:
http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4-dev

Thanks,
-Bryan

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-13-2011, 08:01 PM
Tim Gardner
 
Default : 2.6.38.2 based updates

On 04/13/2011 09:47 AM, Bryan Wu wrote:

On Wed, Apr 13, 2011 at 8:32 AM, Tim Gardner<tim.gardner@canonical.com> wrote:

On 04/13/2011 07:51 AM, Bryan Wu wrote:


git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4


I presume that you're done rebasing against anything other then Natty
master? So, it needs to be able to do that cleanly and without conflict. I
just tried your branch against Ubuntu-2.6.38-8.42 and it failed.



Because the Linaro kernel is kind of merging 2.6.38.2 patches instead
of rebasing, I also got rebasing issue before. Currently, in my tree:

Linaro 2.6.38.2 from npitre (base) + Patches from Sebjan and Andy
Green + Our Ubuntu Delta patches (same from master) + ti-omap4 branch
specific patches.

So I just added patches from 2.6.38-8.41 and -8.42 on top of our
Ubuntu Delta patches, then rebase ti-omap4 branch patches on it again.

Please find the branch here:
http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4-dev

Thanks,
-Bryan



I think for this final pass you must choose Natty master as the base,
then rebase everything else on top. I'm assuming the only conflicts
should be stable commits from npitre's tree (which you can skip) because
Natty master is already up to 2.6.38.2.


My goal is to be able to 'git rebase master' from the ti-omap4 branch
without conflicts.


rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-13-2011, 11:33 PM
Bryan Wu
 
Default : 2.6.38.2 based updates

On Wed, Apr 13, 2011 at 1:01 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> On 04/13/2011 09:47 AM, Bryan Wu wrote:
>>
>> On Wed, Apr 13, 2011 at 8:32 AM, Tim Gardner<tim.gardner@canonical.com>
>> *wrote:
>>>
>>> On 04/13/2011 07:51 AM, Bryan Wu wrote:
>>>>
>>>> git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4
>>>
>>> I presume that you're done rebasing against anything other then Natty
>>> master? So, it needs to be able to do that cleanly and without conflict.
>>> I
>>> just tried your branch against Ubuntu-2.6.38-8.42 and it failed.
>>>
>>
>> Because the Linaro kernel is kind of merging 2.6.38.2 patches instead
>> of rebasing, I also got rebasing issue before. Currently, in my tree:
>>
>> Linaro 2.6.38.2 from npitre (base) + Patches from Sebjan and Andy
>> Green + Our Ubuntu Delta patches (same from master) + ti-omap4 branch
>> specific patches.
>>
>> So I just added patches from 2.6.38-8.41 and -8.42 on top of our
>> Ubuntu Delta patches, then rebase ti-omap4 branch patches on it again.
>>
>> Please find the branch here:
>>
>> http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4-dev
>>
>> Thanks,
>> -Bryan
>
>
> I think for this final pass you must choose Natty master as the base, then
> rebase everything else on top. I'm assuming the only conflicts should be
> stable commits from npitre's tree (which you can skip) because Natty master
> is already up to 2.6.38.2.
>

I've tried several method to do rebase or just 'git am' patches, which
cause all kinds of conflicts. Since the Linaro kernel is not linear
and it looks like this:
2.6.38 (base) + Linaro patches part 1 + merging 2.6.38.1 + Linaro
patches part 2 + merging 2.6.38.2 + Linaro other patches. So it is
quite hard to rebase or git am now.

I generated 1633 patches which is on top of "Linux 2.6.38" release.
The very first patch of them can not be applied on top of our master
branch. I really wanna try to move these 1633 patches onto our master,
but it looks like mission impossible.

> My goal is to be able to 'git rebase master' from the ti-omap4 branch
> without conflicts.
>

I'm afraid that it is quite hard to make this. So for further SRU and
CVE updates, I have to suggest that I cherry pick those update patches
on top of our ti-omap4 instead of rebasing.

apw, we were discussing about a common git weird problem, could you
please give us some help:

in ti-omap4 tree, I just wanna get all the patches on top of a commit
which is 2.6.38 kernel release. So I found that SHA ID of that commit
and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very
strange, I got lots of patches which are not on top of that commit.

So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633
patches on top of that 2.6.38 release commit.

Do you know why I failed to get right patches with the SHA ID? and if
you have time, could you take a look at my ti-omap4 branch? Is that
possible for us to rebase to master now?

Thanks a lot,
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer * *+86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd. * * *www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-13-2011, 11:53 PM
"Dechesne, Nicolas"
 
Default : 2.6.38.2 based updates

On Thu, Apr 14, 2011 at 1:33 AM, Bryan Wu <bryan.wu@canonical.com> wrote:


in ti-omap4 tree, I just wanna get all the patches on top of a commit

which is 2.6.38 kernel release. So I found that SHA ID of that commit

and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very

strange, I got lots of patches which are not on top of that commit.



So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633

patches on top of that 2.6.38 release commit.


you might get confused by the definition of 'on top'. 'on top' as being a child, or 'on top' as being more recent.

git log A.. will list all commits who are not an ancestor of A, which are reachable in your branch. but some of these commits can be older than A, and still aren't ancestor of A.



to me git format-patch A.. if run from your branch, will list all the commits which are in our OMAP4 branch but not in ubuntu master.



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-14-2011, 12:20 AM
Bryan Wu
 
Default : 2.6.38.2 based updates

On Wed, Apr 13, 2011 at 4:53 PM, Dechesne, Nicolas <n-dechesne@ti.com> wrote:
>
>
> On Thu, Apr 14, 2011 at 1:33 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
>>
>> in ti-omap4 tree, I just wanna get all the patches on top of a commit
>> which is 2.6.38 kernel release. So I found that SHA ID of that commit
>> and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very
>> strange, I got lots of patches which are not on top of that commit.
>>
>> So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633
>> patches on top of that 2.6.38 release commit.
>
> you might get confused by the definition of 'on top'. 'on top' as being a
> child, or 'on top' as being more recent.
>
> git log A.. will list all commits who are not an ancestor of A, which are
> reachable in your branch. but some of these commits can be older than A, and
> still aren't ancestor of A.
>

Hmmm, I still fail to understand how come the commits shown in git log
A.. is old than A. Or maybe the time stamps of commits are not in the
right order, but the order in git log A.. should be the order we apply
patches.

> to me git format-patch A.. if run from your branch, will list all the
> commits which are in our OMAP4 branch but not in ubuntu master.
>

Oh, really, so weird. on my side.

git log --online
---
d80d499 OMAP: DSS2: DSI: fix IRQ debug prints
773b30b OMAP: DSS2: DSI: catch DSI errors in send_bta_sync
f34bd46 OMAP: DSS2: DSI: use ISR for BTA in framedone
f36a06e OMAP: DSS2: DSI: use ISR in send_bta_sync
4ae2ddd OMAP: DSS2: DSI: Add ISR support
69b281a OMAP: DSS2: DSI: Restructure IRQ handler
4964111 OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
31ef823 OMAP: DSS2: FEATURES: Functions to return min and max values
of parameters
235e7db OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and
dss_clk_source_name
521cb40 Linux 2.6.38
4c4070a Merge branch 'for-rmk-devel-stable' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson
into devel-stable
5821c95 Merge branch 'davinci-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci
into devel-stable
59766ed Merge branch 'fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-2.6-mn10300
---

So I think the first patch is supposed to generate is commit "235e7db"
OMAP2PLUSS: DSS2 patch. But in following output, the first patch I got
is a patch for i.MX50

---
roc@roc-samos:~/work/natty$ git format-patch 521cb40..
0001-ARM-i.MX50-Rename-devices-mx50.h.patch
0002-arm-mx50_rdp-add-fec-support.patch
0003-arm-mx50_rdp-add-i2c-bus-support.patch
0004-Introduce-VPR200-board.patch
0005-ARM-i.MX53-Add-full-iomux-support-for-mx53.patch
0006-ARM-mx5-Use-dummy-clock-for-the-keypad.patch
0007-ARM-mxs-add-ocotp-read-function.patch
0008-ARM-mxs-mx28evk-read-fec-mac-address-from-ocotp.patch
0009-msm-Add-CPU-queries.patch
0010-msm-Generalize-timer-register-mappings.patch
0011-msm-Generalize-QGIC-registers.patch
0012-msm-io-I-O-register-definitions-for-MSM8960.patch
0013-msm-Physical-offset-for-MSM8960.patch
0014-msm-irqs-8960-Interrupt-map-for-MSM8960.patch
---

Thanks,
-Bryan

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-14-2011, 05:33 AM
Andy Whitcroft
 
Default : 2.6.38.2 based updates

On Wed, Apr 13, 2011 at 05:20:51PM -0700, Bryan Wu wrote:
> On Wed, Apr 13, 2011 at 4:53 PM, Dechesne, Nicolas <n-dechesne@ti.com> wrote:
> >
> >
> > On Thu, Apr 14, 2011 at 1:33 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> >>
> >> in ti-omap4 tree, I just wanna get all the patches on top of a commit
> >> which is 2.6.38 kernel release. So I found that SHA ID of that commit
> >> and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very
> >> strange, I got lots of patches which are not on top of that commit.
> >>
> >> So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633
> >> patches on top of that 2.6.38 release commit.
> >
> > you might get confused by the definition of 'on top'. 'on top' as being a
> > child, or 'on top' as being more recent.
> >
> > git log A.. will list all commits who are not an ancestor of A, which are
> > reachable in your branch. but some of these commits can be older than A, and
> > still aren't ancestor of A.
> >
>
> Hmmm, I still fail to understand how come the commits shown in git log
> A.. is old than A. Or maybe the time stamps of commits are not in the
> right order, but the order in git log A.. should be the order we apply
> patches.

This is because A..HEAD is not all commits newer than A, it is all
commits which became included in HEAD since A.


X ... Y ... Z ... A ... B ... C
R ... S ....../

So for example B here merges in R and S which are older than A, but
which were not in the tree at A but are at C.

Note that this also implies that given a merge ridden source there may
actually not be any linear order that they will correctly apply. Any
linear order that git log offers you is a mearly an approximation of the
correct order and a known to work order does not exist.

> > to me git format-patch A.. if run from your branch, will list all the
> > commits which are in our OMAP4 branch but not in ubuntu master.
> >
>
> Oh, really, so weird. on my side.
[...]
Hard to see from those what is and is not expected without the tree
itself to play with. Will try and look at that and see what the best
way out of this is.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-14-2011, 12:41 PM
Andy Whitcroft
 
Default : 2.6.38.2 based updates

On Wed, Apr 13, 2011 at 07:51:00AM -0700, Bryan Wu wrote:
> Tim,
>
> I've got latest updates from Sebastien Jan and Andy Green
> Please find the branch here:
> git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4
>
> It's based on latest 2.8.38.2 Linaro release and it is also contains
> some updates since previous rebasing:
> * config updates to fix some booting issues like oops and warnings
> * fixed a tracing conflict due LTTng merger in Linaro kernel
> * Rebased to 2.6.38.2 based Linaro kernel release
> * Updates WLAN/BT/FM/Audio supporting from Andy Green and Sebastien Jan
> (u0 tag of for-ubuntu branch in Andy's tree)
> * Rebased to Ubuntu master branch from 2.6.38-7.38 to 2.6.38-8.40

I have been looking at the ti-omap4 branch we are using, as we would
prefer for this to be a rebasable branch as-per all of the other
derivative branches. However this branch is based off of the Linaro
mainline branches which I suspect will render this very difficult indeed
if we wish to maintain any of the history intact (more on this later).

First a little history for completeness. When Linaro started up we had
some discussions with them on how they might maintain their kernel trees.
We did discuss the issues that using a non-rebase model would produce
downstream, partically for the distro. The Linaro tree still did end up
being a merge based tree as it simplifies the upstream management of the
tree (aiui), and that is their primary focus.

The Linaro v2.6.38.2 base that was used for the currently proposed pull
request is actually a very different tree to mainline v2.6.38.2. If I have
done my maths right there are some 2k commits from v2.6.38.2 to the tip.
This is in large part due to the large portions of v2.6.39-rc code which
the updates pull in for arm to get their required functionality, this
includes tracing updates etc hitting things all over the tree (not just
in arm/).

As the linaro base tree and its sources are all merge trees there is no
single guarenteed patch application order for the patches it represents.
This means that any attempt to flatten this 2k patch stream into a linear
rebasable chain is very, very likely to throw up essentially false merge
conflicts which have to be resolved and these in turn engender inverse
conflicts later in the stack. With so very many patches and worse so many
merges this is increasingly likely to occur, and I predict this will make
it near impossible to convert it into a rebase tree in its current form.

There seem to be two viable approaches (to my eye), though I am fully
open to other ideas:

1) squash the delta into a 'omap4' patch and carry that, or
2) accept that this is a merge based tree and develop new handling for
this kind of tree.

For (1) we would essentially do a 'git diff v2.6.38.2..linaro' and apply
the non-ubuntu, non-debian part of it as a single patch against the master
branch. This would then be semantically a rebaseable tree against master.
The upside here is that its handling would be indenticle to that of the
other derivative branches. The downside is that we would lose all the
history and would struggle when rebasing should the delta patch fail to
apply at any time as it will be a humungous patch. We would also have
a harder time working out if there are any additional changes in the
linaro tree needing pulling in (assuming there is any maintenance coming
from linaro).

For (2) we would have to accept that this branch type is different,
that it is not a rebase tree. Maintenance of this branch would be via
merges _from_ the master branch. That is we would work master as normal,
but to gain the benefits of those changes in the ti-omap4 branch we would
merge the latest master release tag into the tip of ti-omap4; rather than
rebase ti-omap4. The newly merged tip would be packaged up and released
as normal. The upside here is that we would be able to merge both from
linaro to get any fixes from them, and also from master to gain security
and other goodness. The downside is the proceedure for doing the updates
to this branch would be different.

I personally think that with a little work option (2) could work for us,
although slighly different, the actual amount of work required to perform
the merge should be similar in order and complexity as that required
for a rebase. As I suspect we are going to get more of these derivative
branches based on Linaro bases going forward given the popularity of ARM
and the long lead times getting ARM into a more generic form (which seems
is still 1-2 years out), I suspect having a simple way to maintain them
will be beneficial.

I think that we should use this oppotunity to trialing method (2) for
this branch. Should this turn out to be a mistake for any reason, there
should be little barrier to converting it to method (1) in the future;
the effort to convert is minimal and does not become more complex for a
trial of (2).

In order to test the viability of method (2) I have played about with the
current ti-omap4 branch as I think that the current rebasing of the Ubuntu
delta onto the top of the linaro branch simply gains us nothing and indeed
is rather confusing. As the linaro tree is already a merge based tree,
I think it makes much more sense to simply use git merging to integrate
the ubuntu delta from the ubuntu master branch. By merging master now,
we can then use merge to later pull in changes from the master branch.
To demonstrate this I have rebuilt a new ti-omap4 branch which would be
more suitable for method (2) above. I have since then experimentally
merged it up to 2.6.38-8.41 and -8.42 to test the viability of this
mechanism. So far it is looking pretty workable. I have pushed this
newly merged branch up as below:

git://kernel.ubuntu.com/apw/ubuntu-natty ti-omap4

In summary, if we think we are going to have more of these Linaro based
branches I think we should seriously consider having a methodology for
handling these, accepting that we may have to handle two different types
of branch in the short term. I think the handling of them can be simple,
though different from our current branches.

I am happy to document this methodology if we are going this route.
Likely an in tree marker to make it easy to tell is appropriate.

Comments?

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 04-14-2011, 03:01 PM
Bryan Wu
 
Default : 2.6.38.2 based updates

On Thu, Apr 14, 2011 at 5:41 AM, Andy Whitcroft <apw@canonical.com> wrote:
> On Wed, Apr 13, 2011 at 07:51:00AM -0700, Bryan Wu wrote:
>> Tim,
>>
>> I've got latest updates from Sebastien Jan and Andy Green
>> Please find the branch here:
>> * * * *git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4
>>
>> It's based on latest 2.8.38.2 Linaro release and it is also contains
>> some updates since previous rebasing:
>> * * config updates to fix some booting issues like oops and warnings
>> * * fixed a tracing conflict due LTTng merger in Linaro kernel
>> * * Rebased to 2.6.38.2 based Linaro kernel release
>> * * Updates WLAN/BT/FM/Audio supporting from Andy Green and Sebastien Jan
>> * * (u0 tag of for-ubuntu branch in Andy's tree)
>> * * Rebased to Ubuntu master branch from 2.6.38-7.38 to 2.6.38-8.40
>

Thanks Andy for taking almost one day to hep this!

> I have been looking at the ti-omap4 branch we are using, as we would
> prefer for this to be a rebasable branch as-per all of the other
> derivative branches. *However this branch is based off of the Linaro
> mainline branches which I suspect will render this very difficult indeed
> if we wish to maintain any of the history intact (more on this later).
>
> First a little history for completeness. *When Linaro started up we had
> some discussions with them on how they might maintain their kernel trees.
> We did discuss the issues that using a non-rebase model would produce
> downstream, partically for the distro. *The Linaro tree still did end up
> being a merge based tree as it simplifies the upstream management of the
> tree (aiui), and that is their primary focus.
>
> The Linaro v2.6.38.2 base that was used for the currently proposed pull
> request is actually a very different tree to mainline v2.6.38.2. *If I have
> done my maths right there are some 2k commits from v2.6.38.2 to the tip.
> This is in large part due to the large portions of v2.6.39-rc code which
> the updates pull in for arm to get their required functionality, this
> includes tracing updates etc hitting things all over the tree (not just
> in arm/).
>
> As the linaro base tree and its sources are all merge trees there is no
> single guarenteed patch application order for the patches it represents.
> This means that any attempt to flatten this 2k patch stream into a linear
> rebasable chain is very, very likely to throw up essentially false merge
> conflicts which have to be resolved and these in turn engender inverse
> conflicts later in the stack. *With so very many patches and worse so many
> merges this is increasingly likely to occur, and I predict this will make
> it near impossible to convert it into a rebase tree in its current form.
>

Exactly, for Linaro release we found it merges several branches from
upstream and stable tree, while for TI OMAP4 patches (come from Sebjan
and Andy Green) are all linear I think.

> There seem to be two viable approaches (to my eye), though I am fully
> open to other ideas:
>
> 1) squash the delta into a 'omap4' patch and carry that, or
> 2) accept that this is a merge based tree and develop new handling for
> * this kind of tree.
>
> For (1) we would essentially do a 'git diff v2.6.38.2..linaro' and apply
> the non-ubuntu, non-debian part of it as a single patch against the master
> branch. *This would then be semantically a rebaseable tree against master.
> The upside here is that its handling would be indenticle to that of the
> other derivative branches. *The downside is that we would lose all the
> history and would struggle when rebasing should the delta patch fail to
> apply at any time as it will be a humungous patch. *We would also have
> a harder time working out if there are any additional changes in the
> linaro tree needing pulling in (assuming there is any maintenance coming
> from linaro).
>

Right, this is a quick fix and we got a rebase tree, but we will lose
history and might be difficult for bisect in the future. Also we might
got conflicts for cherry pick patches from Linaro or stable or SRU,
that will be very painful to fix those conflicts since we wouldn't
have the history.

> For (2) we would have to accept that this branch type is different,
> that it is not a rebase tree. *Maintenance of this branch would be via
> merges _from_ the master branch. *That is we would work master as normal,
> but to gain the benefits of those changes in the ti-omap4 branch we would
> merge the latest master release tag into the tip of ti-omap4; rather than
> rebase ti-omap4. *The newly merged tip would be packaged up and released
> as normal. *The upside here is that we would be able to merge both from
> linaro to get any fixes from them, and also from master to gain security
> and other goodness. *The downside is the proceedure for doing the updates
> to this branch would be different.
>

Actually, this is exactly what I want. And since the difficulty of
changing current ti-omap4 to a rebasable tree, this method is much
easier for us to manage and update in the future.

But I don't use merge, because I wanna keep the master Ubuntu delta
together for this specific 1208.11 release.
I git format-patch to get all master patches since 2.6.38.2 stable,
since our master is rebasable. I will get maybe several hundreds
patches.
I git am them on top of "for-ubuntu" branch from Andy Green, which
contains TI patches based on Linaro 2.6.38.2.
Then add all ti-omap4 specific Ubuntu things on top of it. So current
tag of master is 2.6.38-8.42, I've pushed it to
http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4-dev
And for sure, I fixed some conflicts.

Since this updates is kind of replace the ti-omap4 branch since
1207.10 release, I put master Ubuntu delta together. After 1207.10 is
uploaded, I will just git am further master patches, TI OMAP4 patches
and Linaro patches on top of 1207.10 release, also pack them up.

Instead of merging, I think git am can keep the same linear order and
patches info as master.

> I personally think that with a little work option (2) could work for us,
> although slighly different, the actual amount of work required to perform
> the merge should be similar in order and complexity as that required
> for a rebase. *As I suspect we are going to get more of these derivative
> branches based on Linaro bases going forward given the popularity of ARM
> and the long lead times getting ARM into a more generic form (which seems
> is still 1-2 years out), I suspect having a simple way to maintain them
> will be beneficial.
>
> I think that we should use this oppotunity to trialing method (2) for
> this branch. *Should this turn out to be a mistake for any reason, there
> should be little barrier to converting it to method (1) in the future;
> the effort to convert is minimal and does not become more complex for a
> trial of (2).
>
> In order to test the viability of method (2) I have played about with the
> current ti-omap4 branch as I think that the current rebasing of the Ubuntu
> delta onto the top of the linaro branch simply gains us nothing and indeed
> is rather confusing. *As the linaro tree is already a merge based tree,
> I think it makes much more sense to simply use git merging to integrate
> the ubuntu delta from the ubuntu master branch. *By merging master now,
> we can then use merge to later pull in changes from the master branch.
> To demonstrate this I have rebuilt a new ti-omap4 branch which would be
> more suitable for method (2) above. *I have since then experimentally
> merged it up to 2.6.38-8.41 and -8.42 to test the viability of this
> mechanism. *So far it is looking pretty workable. *I have pushed this
> newly merged branch up as below:
>
> * *git://kernel.ubuntu.com/apw/ubuntu-natty ti-omap4
>

That's great, I think it is also workable for me.

> In summary, if we think we are going to have more of these Linaro based
> branches I think we should seriously consider having a methodology for
> handling these, accepting that we may have to handle two different types
> of branch in the short term. *I think the handling of them can be simple,
> though different from our current branches.
>

I'd love to maintain this difference and work on SRU and CVE updates
for ti-omap4 branch of Natty.

> I am happy to document this methodology if we are going this route.
> Likely an in tree marker to make it easy to tell is appropriate.
>
> Comments?
>
> -apw
>

Thanks a lot,
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer * *+86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd. * * *www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 12:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org