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
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
