[Ovmsdev] changes.txt
Michael Balzer
dexter at expeedo.de
Fri Apr 13 00:44:39 HKT 2018
To make looking up all fixes easier for users we can include a git log as a second file.
Github reported issues will be discussed on github so people involved will already be informed. So I think we should apply rules 1-3 for their inclusion in the
general changes report.
I think that will work well.
Regards,
Michael
Am 12.04.2018 um 08:06 schrieb Mark Webb-Johnson:
> Taking into account Steve and Greg feedback, perhaps we need to define the criteria for what should be in there?
>
> I think we need to focus on what is useful to the user. In particular things that we’ve done that may impact his usage experience.
>
> I suggest a short one or two line summary headline. Then, individual points to cover:
>
> 1. User visible changes
> 2. Changes to functionality that could impact users
> 3. Enhancements and new features that would be of benefit to users
> 4. Github reported issues addressed
>
>
> I am not sure about #4. Should we be reporting ALL github issues, or just those that meet the first three criteria?
>
> Looking at the example, and what @Michael suggests removing, I think that would keep:
>
> * Wifi scan responsiveness
> * The “Server v2: 50 ms delay …” should probably be a github reported issue.
> * Watchdogs (included because it could impact users if they suddenly start to see random reboots, but I agree that this is borderline for inclusion)
>
>
> I don’t think the SD CARD issue meets the above inclusion criteria. But, somebody who had been having issues with his SD CARD would probably be interested in
> knowing we have made changes to try to make it better.
>
> Does that work?
>
> Regards, Mark.
>
>> On 12 Apr 2018, at 12:13 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark,
>>
>> I would reduce this much further to:
>>
>> ????-??-?? ??? ??????? OTA release
>> - Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics
>>
>> This is IMO the only change from the current log a normal user needs to know about.
>>
>>
>> The SD card configuration is on the edge, I would remove that entry from the user info as well, as a normal user will (should) not need to touch these configs:
>>
>> - SD CARD: Provide configurable sdcard parameters:
>> sdcard [maxfreq.khz] = 16000 Maximum frequency (in kHz) of SD CARD bus
>> sdcard [automount] = yes Automatically mount SD CARD on insertion
>>
>> The DebugCrash records info is also on the edge, I would now also remove that from the changes file as no normal user can make use of that info:
>>
>> - Boot: store & send crash debug info (*-OVM-DebugCrash records)
>>
>> The remaining changes are bug fixes or internal stuff no user needs to know, only developers:
>>
>> - Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan)
>> - Server v2: Introduce a 50ms delay between setting charge mode and current in same command
>> - Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions
>> to the event task (removing housekeeping task)
>> - Core: Enable watchdogs for production builds
>> - SD CARD: Reliability improvements to SD CARD auto-mounting on insertion
>> - Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug
>> https://github.com/espressif/esp-idf/issues/1837
>>
>> All this can be reduced to a single line "lots of bug fixes and optimizations".
>>
>> Am I too radical on this?
>>
>> Regards,
>> Michael
>>
>>
>> Am 11.04.2018 um 02:06 schrieb Mark Webb-Johnson:
>>>
>>> Yes, that is the intention. For v2, I generally did this for each firmware release by doing a ‘git lola’ (like your 'git log --oneline --no-merges’), going
>>> through the changelog, and updating the changes.txt with non technical translations of core functionality changes. Trivial changes were not recorded in
>>> changes.txt.
>>>
>>> I just reviewed the latest, and this is what I came up with:
>>>
>>> $ git log --oneline --no-merges 3.1.003 master
>>> aeb7728 (HEAD -> master) Tesla Model S: Refinements for v.e.handbrake and Mph/Kph support
>>> 52e8214 (origin/master, origin/HEAD) Web shell: touch keyboard optimization
>>> 2eab5d3 Provide configurable parameters for sdcard: sdcard [maxfreq.khz] = 16000 sdcard [automount] = yes
>>> a2804b8 Add ovms_utils.h for FormatHexDump.
>>> 343ad45 Reimplement setting console prompt for secure mode
>>> 09f6f6b Tesla Model S: Use 32bit arithmetic for data decoding
>>> ed4d700 Tesla Model S: Use 32bit arithmetic for data decoding
>>> 6f732b2 Improve hexdump of 're list' to show ascii printable characters.
>>> 82cccc7 Tesla Model S: Gear selector - on/awake
>>> 3e0d5b1 TeslaModelS: v.bat.soc and v.pos.speed metrics
>>> e898c1b TeslaModelS: Fix for metric v.bat.soc
>>> c5bc34a TeslaModelS: Fix for metric v.pos.speed
>>> ad46fb2 Clone data passed to SignalEvent
>>> ed32467 Default production config support for ESP IDF panic stub
>>> b38b0ef Mutex protect fsync function call, on logging, to workaround ESP IDF bug https://github.com/espressif/esp-idf/issues/1837
>>> 37c5f4b Boot: store & send crash debug info (*-OVM-DebugCrash records) Note: needs esp-idf update (daef4b5c11a646b7149bf3534e338f3070ae3abf)
>>> 1bcbef9 Clone data passed to SignalEvent
>>> d9931cb Changelog update
>>> be39917 Run SD CARD automount in Events task context, not Timer.
>>> f0969a3 Refactor housekeeping/events tasks to use Events task for signal dispatch and housekeeping.
>>> 97775cf OVMS task naming cleanup
>>> 90c00b8 Enable watchdog reset for production builds
>>> fde6d8d OVMS task naming cleanup
>>> f6a8de5 changes.txt update
>>> 7ea18b4 Server v2: Delay 50ms on cmd #16 (between setting mode and current)
>>> 21e4110 Increase wifi scan responsiveness
>>>
>>>
>>> Becomes:
>>>
>>> ????-??-?? ??? ??????? OTA release
>>> - Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan)
>>> - Server v2: Introduce a 50ms delay between setting charge mode and current in same command
>>> - Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions
>>> to the event task (removing housekeeping task)
>>> - Core: Enable watchdogs for production builds
>>> - SD CARD: Reliability improvements to SD CARD auto-mounting on insertion
>>> - SD CARD: Provide configurable sdcard parameters:
>>> sdcard [maxfreq.khz] = 16000 Maximum frequency (in kHz) of SD CARD bus
>>> sdcard [automount] = yes Automatically mount SD CARD on insertion
>>> - Boot: store & send crash debug info (*-OVM-DebugCrash records)
>>> - Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug
>>> https://github.com/espressif/esp-idf/issues/1837
>>> - Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics
>>>
>>>
>>> This process is helped if people can include full information in their commit messages - in particular for changes that impact features, usage, provide new
>>> options, etc - anything that is going to affect or be visible to the user.
>>>
>>> Currently, the firmware download server has a file (http://api.openvehicles.com/firmware/ota/[v3.0|v3.1]/<tag>/ovms3.ver
>>> <http://api.openvehicles.com/firmware/ota/%5Bv3.0%7Cv3.1%5D/%3Ctag%3E/ovms3.ver>) that stores a one-line ‘current version’. I plan to change that to include
>>> the last few releases for changes.txt (as well as the version). That way, ‘ota status’ can show the changes in the latest version as well as the version
>>> number itself).
>>>
>>> Regards, Mark.
>>>
>>>> On 11 Apr 2018, at 5:31 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> A suggestion for the changes.txt:
>>>>
>>>> I thought and now suggest this file is intended as an extract of high level changes, i.e. changes that extend or change the user interface and/or features of
>>>> the system, but not bug fixes or internal reworks.
>>>>
>>>> A log of all changes can be created automatically from the git log, no need to do that manually.
>>>>
>>>> git log --oneline --no-merges 3.1.000..
>>>>
>>>> If we add all commits, users will stop reading this file. If we reduce it to high level entries, it becomes a valuable info for users.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> --
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180412/a29ad64e/attachment.htm>
More information about the OvmsDev
mailing list