|Code Slush - September 29||ciwrl||9/26/12 9:15 AM|
A code slush is tentatively scheduled for this coming Saturday, September 29th. Please make sure anything important is submitted to gerrit by that date.
Arcee is out of town until Saturday and will take the first pass at merging in patches on Sat/Sunday upon his return.
Cyanogen will be out of town until Monday and will take the final pass at mergers when he returns.
This effectively puts a hard code freeze on Tuesday October 2nd, for the CM10-M2 release sometime later that week (likely the 6th or 7th of October).
All devices that received an M1 release will default to receiving a M2 unless you respond here to hold it. Devices that didn't get an M1 (and are ready for M2) should update their status on the Device Readiness page http://goo.gl/41PyS. If you cannot view the document, ping me with your email and I will update your access.
|Re: Code Slush - September 29||ciwrl||9/26/12 9:28 AM|
Also, there are outstanding projects on the Gerrit/Github document that need to be created.
Jef, since the others are out, please take a look at those as soon as possible so we have then ready before Friday evening.
|Re: Code Slush - September 29||Andy||9/27/12 5:41 AM|
What we have right now is a major patch for Exynos 4210 devices that is looking to be almost ready - but we can't declare it ready until the P62xx/P68xx guys test it, and Alan is not returning from a trip until the 29th.
Without this patch, 4210 devices cannot be considered for M2, but with it, I think they'll be ready.
Is there a possibility of a few days extension so this patch can be properly tested?
|Re: Code Slush - September 29||ciwrl||9/27/12 9:29 AM|
Since the final merge actions are Monday, is that enough time for you guys?
|Re: Code Slush - September 29||Andy||9/27/12 9:42 AM|
Dunno. And after chatting with codeworkx this morning, I'm questioning whether we want to go for an M build. After looking at bugtracker for CM9 stable, I'm beginning to think we lowered our standards a bit too much to allow Exynos devices to make the grade. Probably we should keep higher standards this time around, even if it means these devices will never get M builds or stable. We shouldn't lower our standards because Samsung won't cooperate with source code and documentation for Exynos that matches the quality available for Qcom and TI chips via CAF and omapzoom respectively.
|Re: [cm-dev] Re: Code Slush - September 29||cyanogen||9/27/12 9:46 AM|
Which of the Exynos device maintainers will be at the BBQ?
|Re: [cm-dev] Re: Code Slush - September 29||codeworkx||9/27/12 10:02 AM|
Me not because it's on the other side of our globe. ;-)
2012/9/27 Steve Kondik <steve....@gmail.com>
|Re: [cm-dev] Re: Code Slush - September 29||Andy||9/27/12 5:25 PM|
I will be, I think that's it... atinm is pretty much retired, everyone else lives in another country.
|Re: [cm-dev] Re: Code Slush - September 29||ciwrl||10/3/12 7:49 AM|
Way to get off-topic Steve :p
Ricardo/Steve: Dvtonder has identified a gap in the CM updater logic that should be patched ASAP and merged before the next nightly and prior to the pending code freeze. He'd do it himself, but he is currently afk for the time being (incidentally, apparently you two don't have him circled in G+ so he couldn't gtalk you).
The gap: the updater currently does not initiate a check to see if the download destination folder exists prior to initiating the download. This causes the download to instantly fail. Logic should be added to both: 1) check to see if the download destination folder exists and 2) in the event that it doesn't, the updater should create it.
Additionally, Jef, I am in contact with gweedo767 (he's worked with Koush on recovery items). He would like to integrate BBQLog (http://changelog.bbqdroid.org/) into the updater so we have an actively generated changelog. I've told him to contact you via devrel to see if we can get an instance of the json parser and additional setup on to CM servers (https://github.com/BBQDroid/BBQLog). I'd imagine that CM control over the server the webview would use would be a prerequisite to any such functionality added. Just a heads up. For what its worth, I do think this is a good idea, as we have recently dropped the ball on updating changelogs for both CM9 and CM 10-M1
|Re: [cm-dev] Re: Code Slush - September 29||DvTonder||10/3/12 7:55 AM|
Fix for the folder issue should be in UpdatesSettings.java, somewhere around line 298. Can leverage the logic as lines 630 and 632.
Can I also ask that this be merged before code freeze, please -> http://review.cyanogenmod.com/#/c/24235/ that should be it for the updater this go-around.
|Re: [cm-dev] Re: Code Slush - September 29||arcee||10/3/12 8:06 AM|
We have much better (and simpler, and complete) ways of doing changes. I just implemented them :-P
|Re: [cm-dev] Re: Code Slush - September 29||cybik||10/3/12 8:16 AM|
actually, there might be another bug with the updater: start an update download, and then put the phone sideways. Last time i did this, it killed the download.
2012/10/3 arcee <ricardo....@gmail.com>
|Re: [cm-dev] Re: Code Slush - September 29||Jef Oliver||10/3/12 9:14 AM|
Pics or it didn't happen.--
Sent from my private plane above unknown islands
|Re: [cm-dev] Re: Code Slush - September 29||DvTonder||10/3/12 9:18 AM|
yes, was a known issue with the initial commits. This was fixed a day or two ago when we introduced the new download manager
|unk...@googlegroups.com||10/3/12 9:20 AM||<This message has been deleted.>|
|Re: [cm-dev] Re: Code Slush - September 29||DvTonder||10/3/12 9:21 AM|
Arcee, let me know when it is ready to implement. I have a planned design of the User interface for it.
|Re: [cm-dev] Re: Code Slush - September 29||arcee||10/3/12 9:52 AM|
It already is :-P
Starting from today (including the last one or 2 builds), jenkins is generating a full git log immediately before running a build.
(that "CHANGES" file in http://jenkins.cyanogenmod.com/view/All/job/android/9311/)
But it currently only generates the logs as an artifact of jenkins builds. We need a way to make it available (or referenced) through the
get.cm API, so you can "see" it from the updater. It shouldn't be too much of a problem.
|Re: [cm-dev] Re: Code Slush - September 29||DvTonder||10/3/12 10:15 AM|
Would be good if we can pass a build timestamp and device to the API and get the associated changes.
I planned on allowing the user to tap on the build name side of the preference to show the change log for that build - on downloaded builds that currently allows you to delete the build. Was thinking of doing a 'context menu' on the preference that, if clicked will display the option to see the change log and/or delete.
|Re: [cm-dev] Re: Code Slush - September 29||arcee||10/4/12 3:54 AM|
OK, I made a couple of changes last night to make the changes available through the get.cm API. Each build carries its own change listings, and each build JSON object looks like this:
Personally, I'm OK with gweedo's PoC (http://www.youtube.com/watch?v=a6KcGrwA_7s)
|Re: [cm-dev] Re: Code Slush - September 29||Markus Guidry||10/4/12 7:24 AM|
gweedo's PoC seems fine to me also.
|Re: [cm-dev] Re: Code Slush - September 29||DvTonder||10/4/12 7:30 AM|
Thank you. Gweedo and I have been exchanging a lot of messages since last night on fine tuning his design. Its looking really nice already, just need to add in a bit of animation here and there. I will update the update check code to include the changelog text link in the UpdateInfo so it can be used.
|Re: [cm-dev] Re: Code Slush - September 29||ciwrl||10/9/12 9:47 AM|
Going back on topic...again :p
M2 release is slated for tomorrow!
|Re: [cm-dev] Re: Code Slush - September 29||Markus Guidry||10/9/12 11:23 AM|
Will we be including the 4.1.2 fixes/changes in M2 or will that be in M3?
|Re: [cm-dev] Re: Code Slush - September 29||cyanogen||10/9/12 11:45 AM|
4.1.2 won't make it into M2.
|Re: [cm-dev] Re: Code Slush - September 29||cyanogen||10/9/12 12:20 PM|
I'm recanting that statement.
I think we need to include 4.1.2 for this release. It contains a bunch
of security-related stuff. Also, we really don't want to be behind in
the game. I'm working on merging it now.
> changes available through the get.cm <http://get.cm> API.
> Each build carries its own change listings, and each build> <http://www.youtube.com/watch?v=a6KcGrwA_7s>)
>> get.cm <http://get.cm> API, so you can "see" it from
> the updater. It shouldn't be too much of a problem.> <http://changelog.bbqdroid.org/>)
> into the updater so we have an> <https://github.com/BBQDroid/BBQLog>).