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.
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.
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.
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.
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)?
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 :)
Thanks, Andrey