<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Short story: what do people want:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">nightly</li><li class="">edge</li><li class="">main</li></ul></div><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">edge</li><li class="">eap</li><li class="">main</li></ul></div><div class=""><br class=""></div><div class="">?</div><div class=""><br class=""></div><div class="">Long story:</div><br class=""><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class="">Would this structure have helped in finding the ota issue? I mean, are there any developers updating ota from the "edge" releases instead of building themselves?</div></blockquote><div class=""><br class=""></div>There seem to be. I had a few download 3.1.007 from my server. I have two cars on “edge”. Developers actively working on things generally have it in factory and just flash that directly. But developers just running it in their cars seem to use OTA.<div class=""><br class=""></div><div class="">The problem we had this time was that “edge” wasn’t actually built nightly as originally intended (just on-demand, and relatively infrequently) so I didn’t ota update from it and didn’t catch the problem until a few other cars on “edge” had already hit it. If “edge” had seen “3.1.007”, then ‘3.1.007-1”, then “3.1.007-2”, I (and maybe others) would have noticed the problem.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class="">The new structure means beta testers need to change their setup. I suggest introducing a "nightly" for developers instead, placed before "edge”.</div></blockquote></div><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><br class=""></div></div><div class="">As I said before, I am happy to go with the consensus with this. My original plan (in that email back in April) was for:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">main</li><li class="">eap</li><li class="">edge</li></ul><div class=""><br class=""></div><div class=""><div class="">The idea then was that “edge” was “bleeding edge” (nightly builds). “eap” and “main” were more formal release levels.</div></div><div class=""><br class=""></div><div class="">And that is simply what I implemented now. At this stage it is very easy to change the names of “edge” and “eap” to whatever we want. It can be “main”, “edge”, and “nightly” (with “edge” taking on the role of “eap”), but that is different to what was original suggested back in April ("<i class="">The idea is that ‘edge’ will be an automated (at least) nightly build</i>”).</div><div class=""><br class=""></div><div class="">As I said before, I am happy to go with the consensus on this. I haven’t announced anything, and the user guide is pending update on this, so we can do whatever we want now.</div><div class=""><div><br class=""></div><div><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class="">To harmonize "edge" releases, I also need to know which commits are moved into "edge" then. Up to now we used the "3.1.xxx" version tagging for main releases, you seem to have changed this now with "3.1.008", as the tag is already set but the server still has 3.1.006 in the "main" directory.<br class=""></div></blockquote><div><br class=""></div><div>I think you can poll “ovms.ver” from edge/, eap/, and main/ to see. Or we can arrange rsync, email notification, or something else?</div><div><br class=""></div>The nightly build system produces a git log in ovms.ver (the last 10 commits). I think that "3.1.008-13-g272697e” (for example) means 13 commits beyond 3.1.008, and the “g272697e” is the commit hash show in the log.</div><div><br class=""></div><div>Today (I just checked), we have:</div><div><br class=""></div><div><ul class="MailOutline"><li class="">“edge” has 3.1.008-15-g0631a2</li><li class="">“eap” has 3.1.008</li><li class="">“main” has 3.1.006</li></ul></div><div><br class=""></div><div>That seems correct. We have 3.1.008 in “eap” for a few days, to ensure it doesn’t cause any problems. It seems ok, so should go to “main” later this weekend (and which point we’ll be over the 3.1.007 mess).</div><div><br class=""><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class="">I suggest sticking to the main version tagging as before, as Github uses these to create "releases" (<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases</a>), and adding "3.1.xxx-n-hhhhhh" tags for the "edge" releases.<br class=""></div></blockquote><br class=""></div><div>I am using the tags from our existing build system ("git describe --always --tags --dirty”). As “edge” is a nighty (or on-demand) build, it will see version tags between tagged (3.1.XXX) formal main releases and these will appear as “3.1.xxx-n-hhhhhh”.</div><div><br class=""></div><div>The idea is that when we decide to release a tagged formal main release (3.1.XXX), we will tag it, push the tags, and then do a manual build on “edge”. A few days go by, and if no issues are found that 3.1.XXX release is copied over to “eap”. We then wait a few days (perhaps a week) to ensure no problems reported, and finally move the same “3.1.XXX” to “main”. During that time, “edge” may have progressed from 3.1.XXX to 3.1.XXX-1, to 3.1.XXX-2, etc.</div><div><br class=""></div><div>The “eap” and “main” should only ever see “3.1.XXX” and that should have been running on cars, and been updated from, by the time the firmware gets to “eap”/“main”.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 30 Jun 2018, at 3:40 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
Would this structure have helped in finding the ota issue? I mean,
are there any developers updating ota from the "edge" releases
instead of building themselves?<br class="">
<br class="">
Up to now I followed the approach of testing locally and only
releasing to "edge" what works on my module, as "edge" is what beta
testers are updating from now.<br class="">
<br class="">
If there are developers that update ota:<br class="">
<br class="">
The new structure means beta testers need to change their setup. I
suggest introducing a "nightly" for developers instead, placed
before "edge".<br class="">
<br class="">
To harmonize "edge" releases, I also need to know which commits are
moved into "edge" then. Up to now we used the "3.1.xxx" version
tagging for main releases, you seem to have changed this now with
"3.1.008", as the tag is already set but the server still has
3.1.006 in the "main" directory.<br class="">
<br class="">
I suggest sticking to the main version tagging as before, as Github
uses these to create "releases"
(<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases</a>),
and adding "3.1.xxx-n-hhhhhh" tags for the "edge" releases.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 28.06.2018 um 03:14 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:CD39B847-FC78-4CDC-A9A1-7E6317484730@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
To try to avoid a repeat of the 3.1.007 issue with OTA updates,
I’ve set things up as below:
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">edge: Bleeding edge developer, built
automatically each night with 3.1.XXX-N-HHHHHH style
versioning</li>
<li class="">eap: Early Access Program pre-releases, usually
with 3.1.XXX style versioning</li>
<li class="">main: Stable releases that have completed testing
in EAP, with 3.1.XXX style versioning.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Before moving things edge -> eap, I’ll have a
checklist of regression tests to run (including ota update).
Other functional problems should have been picked up by
developer cars while in ‘edge’ release. I suggest to leave a
particular build in ‘edge’ for a week, to make sure no problems
reported to those early real-world testers, before moving to
‘main’.</div>
<div class=""><br class="">
</div>
<div class="">I have an automated nightly build script that runs
at 4pm UTC (midnight HKT). That pulls the latest masters for
esp-idf and ovms firmware, then builds as appropriate. If there
is something to build (something in git changed), it does it
automatically and produces an email summary like this:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><font class="" face="Andale Mono"><span style="font-size: 14px;" class="">Subject: OVMS Nightly
Firmware Build 3.1.008-13-g272697e</span></font></div>
<div class=""><font class="" face="Andale Mono"><span style="font-size: 14px;" class=""><br class="">
</span></font></div>
<div class=""><font class="" face="Andale Mono"><span style="font-size: 14px;" class="">3.1.008-13-g272697e<br class="">
Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8)<br class="">
<br class="">
Total sizes:<br class="">
DRAM .data size: 17116 bytes<br class="">
DRAM .bss size: 33536 bytes<br class="">
Used static DRAM: 50652 bytes ( 130084 available, 28.0%
used)<br class="">
Used static IRAM: 102096 bytes ( 28976 available, 77.9%
used)<br class="">
Flash code: 1279002 bytes<br class="">
Flash rodata: 598168 bytes<br class="">
Total image size:~1996382 bytes (.bin may be padded
larger)<br class="">
<br class="">
* 272697e (HEAD, origin/master, origin/HEAD, master)
Twizy: no sufficient level info on charge done<br class="">
* 8497d9f Web dashboard: range display min/max exchanged<br class="">
* 5d8f96d Webserver: fix u64 alignment<br class="">
* 5363ab8 TeslaRoadster: Vehicle cooldown command and
implementation<br class="">
* bf3b0d5 TeslaRoadster: Digital Speedo implementation<br class="">
* d0221bf TeslaRoadster: Refuse to lock a car that is ON<br class="">
* 7179600 Update project status files<br class="">
* b3bef78 TeslaRoadster: Digital Speedo implementation<br class="">
* cfbd297 TeslaRoadster: Vehicle cooldown command and
implementation<br class="">
* ec4bc37 Add VehicleModeKey helper function</span></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">At the moment, that summary comes to me. Is there
any use sending it to the ovmsdev mailing list?</div>
<div class=""><br class="">
</div>
<div class="">With developer cars set to ‘edge’, and automatically
updating each night, hopefully with this three stage process we
can pickup on problems before they hit the main stable trunk.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 17 Apr 2018, at 4:35 AM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> "alpha" /
"beta" imply some underlying development & release
plan, i.e. a list of features to be reached for the
"release" version.<br class="">
<br class="">
"stable" and "nightly" are also used, but "nightly"
implies a fixed schedule -- I'd rather have the option
to update manually several times a day --, and "stable"
implies some sort of quality check / warranty, which we
also cannot provide.<br class="">
<br class="">
So I think "main" and "edge" are appropriate.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 16.04.2018 um 03:46
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:B66EC8CD-2ADE-4331-A652-3CBF0D88CABC@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
Another point perhaps missed is that these are really
release tags, not necessarily developer release
stages. So, for example, say we were working on a
branch with a major re-write called v4.x, we could
create a ‘v4x’ branch (or whatever) and release ota
updates to it. Modules subscribing to that tag would
get those updates.
<div class=""><br class="">
</div>
<div class="">I guess we could address that with
v3-beta, v3-alpha, v4-alpha, etc.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 16 Apr 2018, at 9:40 AM, Mark
Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">The original
idea was to have these as release tags that
users could subscribe to. The factory
firmware we have has everyone as ‘main’, so
that one is hard to change.
<div class=""><br class="">
</div>
<div class="">I did consider ‘alpha’, but it
just looked strange to me.</div>
<div class=""><br class="">
</div>
<div class="">The idea is that ‘edge’ will
be an automated (at least) nightly build.</div>
<div class=""><br class="">
</div>
<div class="">I think there is room for one
more like Tesla’s ‘early access program’
(pre-release candidates that should be
stable but have not had widescale
testing). So, my overall suggestion is for
something like:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">main</li>
<li class="">eap</li>
<li class="">edge</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Steve’s alternative would be:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">main</li>
<li class="">beta</li>
<li class="">alpha</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Other than ‘main’, these are
simple to change. Happy to go with the
consensus...</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 16 Apr 2018, at 9:26
AM, Stephen Casner <<a href="mailto:casner@acm.org" class="" moz-do-not-send="true">casner@acm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On Mon, 16 Apr 2018,
Mark Webb-Johnson wrote:<br class="">
<blockquote type="cite" class="">From
now on, I’m going to be
maintaining two tags for the
production<br class="">
ota server <a href="http://api.openvehicles.com/" class="" moz-do-not-send="true">api.openvehicles.com</a>
<<a href="http://api.openvehicles.com/" class="" moz-do-not-send="true">http://api.openvehicles.com/</a>>.
These<br class="">
are:<br class="">
<br class="">
main: for stable releases<br class="">
edge: for bleeding edge
developer releases<br class="">
</blockquote>
<br class="">
Why not the "standard" terms
release (or stable), beta, alpha?<br class="">
<br class="">
--
Steve_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<!--'"--><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>