On 05/03/2013 12:47 PM, Jon Medhurst (Tixy) wrote:

On Thu, 2013-05-02 at 22:40 +0400, Andrey Konovalov wrote:

...

Greetings,

This wiki page:

https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

• is now tracking the linux-linaro kernel rebuilds for 13.05.

v3.9 release based linux-linaro-core-tracking (llct) rebuild has been published, the tag is llct-20130502.0 . The 13.05 linux-linaro release will be v3.10-rc3 based,

I think you may have miscalculated. Isn't the merge window 2 weeks long? In which case, as 3.9 was released this past Monday, we shouldn't expect -rc1 until May 13th and -rc3 will be in June.

Tixy, yes, you are right. I've corrected the LinuxLinaroKernelSchedule.

The 13.05 linux-linaro release will be v3.10-rc2 based, The next step is: May 06: ll rebuild based on llct-20130502.0.

Please let me know if sticking to v3.9 until v3.10-rc1 is out (May 13th) is an issue for the topics.

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 05/06/2013 11:06 PM, Andrey Konovalov wrote:

...

...

...

https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

The 13.05 linux-linaro release will be v3.10-rc2 based,

May 08: ll rebuild based on llct-20130506.0 * Skipped: "make dtbs" broken in llct-20130506.0

May 08: v3.9 based linux-linaro-core-tracking (llct) rebuild (if there are changes to the topics) * Done: the tag is llct-20130508.0 * Changes: - linaro-android-3.9-experimental-fixes topic added to revert commit 5e94686 "ARM: convert build of appended dtb zImage to list of dtbs" - linux-3.9.y topic added to pull the v3.9.1 stable tree updates

The next step is: May 10: ll rebuild based on llct-20130508.0

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 05/15/2013 12:04 AM, Andrey Konovalov wrote:

...

...

...

https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

The 13.05 linux-linaro release will be v3.10-rc2 based,

May 15: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild * Done: the tag is llct-20130515.1 * Changes: . the 3.8-based binder topic re-added . kernel/printk.c: build error in CONFIG_DEBUG_LL=y case fixed . "ARM: crypto: sha1-armv4-large.S: fix SP handling" patch needed to enable CONFIG_CRYPTO_SHA1_ARM

The next step is: May 16: ll rebuild based on llct-20130515.1

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 05/15/2013 10:59 PM, Andrey Konovalov wrote:

On 05/15/2013 12:04 AM, Andrey Konovalov wrote:

...

...

...

...

https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

The 13.05 linux-linaro release will be v3.10-rc2 based,

May 16: ll rebuild based on llct-20130515.1 * Done: the tag is ll-20130516.0 * Changes: . based on v3.10-rc1 . IKS included into integration-linaro-vexpress topic * Known issues: . the Samsung topic hasn't moved to v3.10 yet . panda isn't supported as is (omap4.conf is to be fixed; USB needs verification)

The next step is: May 17: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild * Expected: config fragments updates

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 17 May 2013 09:06, Fathi Boudra fathi.boudra@linaro.org wrote:

On 16 May 2013 22:11, Andrey Konovalov andrey.konovalov@linaro.org wrote:

...

On 05/15/2013 10:59 PM, Andrey Konovalov wrote:

...

On 05/15/2013 12:04 AM, Andrey Konovalov wrote:

...

...

...

> > https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

The 13.05 linux-linaro release will be v3.10-rc2 based,

May 16: ll rebuild based on llct-20130515.1

• Done: the tag is ll-20130516.0
• Changes: . based on v3.10-rc1 . IKS included into integration-linaro-vexpress topic
• Known issues: . the Samsung topic hasn't moved to v3.10 yet . panda isn't supported as is (omap4.conf is to be fixed; USB needs

verification)

U8500 (Snowball) fails to build: fatal error: mach/irqs.h: No such file or directory #include <mach/irqs.h> ^

Issue known upstream and raised already a couple of times.

Linus provided a patch: http://marc.info/?l=linux-kernel&m=136567139910888&w=2

...

The next step is: May 17: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild

• Expected: config fragments updates

...

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 05/16/2013 11:11 PM, Andrey Konovalov wrote:

...

...

...

...

https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule

The 13.05 linux-linaro release will be v3.10-rc2 based

May 17: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild * Done: the tag is llct-20130518.0 * Changes: . big-LITTLE-MP-master-v17 . v3.10 fixes for Snowball (snowball boots ok with DT, but no ethernet) . linaro-base.conf: NFS options enabled

May 19: ll rebuild based on llct-20130515.1 * Done: the tag is ll-20130520.0 * Changes: . Samsung LT's integration topic added back

The next step is: May 20: ll rebuild based on llct-20130518.0

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

Thanks, Andrey

On 22/05/13 02:48, the mail apparently from Andrey Konovalov included:

The next steps are: May 22: ll rebuild based on llct-20130521.0 May 23: ll rebuild based on llct-20130521.0, linux-linaro release candidate, code freeze

...

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

This happened, which is good, but llct has not updated for 3.10-rc3 or 3.10-rc4 yet, which is not good; llct is two weeks old. Something similar happened last month.

I realize this isn't the case for everyone but actually the literal "schedule for 13.05" holds zero interest for me.

Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them.

Is it possible things have gotten a little unbalanced with all the excitement of "code freezes", "releases", "schedules" that make the choo-choo noises for the monthly release train set, we're not giving the llct tracking activity enough love?

-Andy

On Tue, 2013-06-04 at 10:10 +0530, Tushar Behera wrote:

...

Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them.

+1.

Another +1 :-)

Well, it's timely updates to linux-linaro I'm most interested in, but that implies regular llct updates as well.

On 05/06/13 04:05, the mail apparently from Andrey Konovalov included:

On 06/04/2013 03:22 AM, Andy Green wrote:

...

On 22/05/13 02:48, the mail apparently from Andrey Konovalov included:

...

The next steps are: May 22: ll rebuild based on llct-20130521.0 May 23: ll rebuild based on llct-20130521.0, linux-linaro release candidate, code freeze

...

The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date).

This happened, which is good, but llct has not updated for 3.10-rc3 or 3.10-rc4 yet, which is not good; llct is two weeks old. Something similar happened last month.

Agreed. This is not good. And I've pushed the llct updates to fix that.

Thanks.

On the other side, I am considering dropping llct as an intermediate step when creating the ll tree. The linux-linaro-stable work done in 13.05 shown that topic dependencies may be more complex, and could not be met by just creating one intermediate tree. The more generic approach seems to add explicit topic dependencies into the manifest, so that the tool to merge the topic together would use this information.

I think that might be telling you that you're trying to get one llct branch to do too many integration angles at once.

There's certainly a place for a tree that just collects a bunch of aligned topic trees like ARMLT vexpress, bl switcher, Androidization and binds them standalone. That's the one we want.

As you do more like solving conflicts between bsp trees you're integrating, we don't want to subscribe to that so it's another, separate step I think.

Another point to mention, is the proposal to merge the board enablement topics first, and the generic features next (the LSK case). This would assume the generic topics to enable their features for "all the linaro supported" boards, or adding separate topic to enable the features for particular boards. This also breaks the current 2-level llct/ll model.

I don't think that's a good idea.... the problem will be the tree is unbuildable from the start when you bind the bsps that depend on the new generic features (vexpress for any big.LITTLE...) but only merge in the dependencies like vexpress later.

It's better if the tree stays buildable as you go for sanity checks if nothing else, merging the generic features without users, then adding the users meets that.

Also I am going to more actively use rebasing the topic to their most recent base w/o topic owners intervention (e.g. like I did for one month for the Samsung LT's integration topic few cycles ago). For the topic owners this would mean something like that if their topic C is based on topics A and B, the topic C must be based on the A and B tip when submitted to for inclusion into linux-linaro(-whatever) tree, and after that it will be automatically rebased onto the most recent version of topic A and B unless there are conflicts requiring the topic owner's help. This is a very rough idea at the moment - I am not quite sure if it could even work.

Yeah we started out with TI tree purely doing rebases and it works as a flow, although with the - frankly - stupid structure of carrying around 2,500 patches of other people's rotting junk being enforced it becomes hard to manage.

Later I realized we're totally compatible with merge if we get them all over with before we rebase our actual bsp tree patches on top as the last guys, that's the approach we take now.

Now we have more control over how to arrange the work we completely ban out history series of patches in our rebase part for the bsp, we squash in topic patches currently limited to just 40 patches, even though a lot of work is going on with them. We use tagging for every working build that's notable to allow capture or understanding of the delta. So the problem of slow or unmanageable rebase is eliminated.

This is another sign that the proposal you mentioned above is broken though, merge management can only happen underneath the rebase part, so you'll need to be be merging the generic trees first...

...

I realize this isn't the case for everyone but actually the literal "schedule for 13.05" holds zero interest for me.

In long term this should evolve into change log / release notes. (I do use it for writing the release notes)

...

Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them.

OK. Could you use ll instead of llct, if ll were updated frequently enough (soon after every -rc at least)?

At the moment with llct I can put my finger on your merges and explain what kind of thing we have in our tree inbetween Linus and our bsp patches, that is nice. (We have some extra trees merged in as well locally like upstream-headed mailbox series).

Last time we discussed this ll already has other bsps merged in, eg, Samsung. At the moment we're basically delivering a "Fujitsu BSP", they like to pass around the whole delta. If I understood it, basing on ll instead of llct is going to radically bloat the delta given to Fujitsu customers with stuff they definitely won't build or care about.

I think ll may have some use from Linaro-wide perspective but right now our tree is not public so we can't participate even (we would be quite aligned if / when it became public).

...

Is it possible things have gotten a little unbalanced with all the excitement of "code freezes", "releases", "schedules" that make the choo-choo noises for the monthly release train set, we're not giving the llct tracking activity enough love?

Seems so. I just don't think that "releases" and "schedules" is a lot of excitement. In the last week of a cycle it is rather a head ache :)

Right now the value we get from llct is things like bl switcher and iks integration, and particularly ARM LT vexpress content that's bang up to date (tixy had 3.10-rc1 stuff like the next day) etc. That makes me happy to see and use, I feel like I'm getting a big boost from llct.

We're starting to make member builds (on a monthly beat) but I wonder how much we will truly care about those. For example it's good to get our special initscripts built into the initramfs for Android, but since we put our modules in there as well, it doesn't get us away from regenerating the initramfs each kernel we build. In Ubuntu case we want to focus on gnome-shell, we anyway have to (slowly) install a ton of stuff in the prebuilt tarball, if we have to stick a custom /etc/X11/xorg.conf in there as well it's not much more effort.

Anything that's deeply Ubuntu-specific like hwpacks (last time I tried to use them, you HAD to deploy them on specifically Ubuntu using QEMU

.<) or Ubuntu desktop acceleration if it has special difficulties

Gnome doesn't, have no special religious meaning for me, if they're not a good direction we won't use them.

The eval boards for the SoCs we work with are not widely available. It's not like there's a big constituency right now that would follow the monthly updates.

For those reasons I think monthly release cadence will continue to be fairly meaningless for us for the time being. Anyway we just started with it so maybe we'll find more uses as we go on.

-Andy