<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Olivier,<br>
<br>
neither module nor App limit the vehicle type to cars. The framework
fits all types of vehicles.<br>
<br>
App support for a new vehicle is normally just adding the images,
plus maybe minor logic changes for the fast charging detection.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 30.05.19 um 09:58 schrieb Olivier:<br>
</div>
<blockquote type="cite"
cite="mid:CAOuNP27ZkcMrvB_jsw1HdJ-cahCCy==uUQxYAAdMN6Ajx1oErQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hello Mark,
<div><br>
</div>
<div>Concerning vehicle, is it too soon to add support for
motorcycle or scooter in the list (like Vectrix VX1) because
the IOS App or Android App is not prepare for than ?</div>
<div><br>
</div>
<div>About restructuring/refreshing, have you plan or think
about upgrade mailman 2.1 to mailman 3.x with something like
hyperkitty ?</div>
<div><br>
</div>
<div>regards, Olivier</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le jeu. 30 mai 2019 à 08:49,
Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net"
moz-do-not-send="true">mark@webb-johnson.net</a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;">
<div>Michael, and others, thanks for your feedback.</div>
<div><br>
</div>
It seems that the consensus is that the change review
process is adding value (particularly for new developers),
so let’s leave the components the way they are.
<div><br>
</div>
<div>I have restructured the forums on <a
href="http://www.openvehicles.com" target="_blank"
moz-do-not-send="true">www.openvehicles.com</a> to have
individual forums for each supported vehicle type. The
updated forum system also now supports read/unread
messages, and you can subscribe for eMail notifications
(by user, topic, thread, and a host of other
possibilities). For example, I went to the sections for
Tesla Roadster and hit the ’subscribe’ button so I get
notified of new posts in that section.</div>
<div><br>
</div>
<div>I see a couple of others users have stumbled upon that
already, and added subscriptions. I am hoping users and
developers for individual vehicle types will use that to
help with supporting other users of their vehicle type
(and from now on I will direct specific vehicle support
questions to those forums).</div>
<div><br>
</div>
<div>I have also standardised the structure in the user
guide, to give each current vehicle their own section, and
have a standardised overview page for each vehicle type.</div>
<div><br>
</div>
<div>Regarding acknowledging developer's efforts, I think
the vehicle sections in the advanced user guide is the
best to keep this maintained. We can also acknowledge
developers in the vehicle specific forum sections. I think
it should be entirely up to the developer whether they
provide contact information, but names of key contributors
would be good to have (so people know who to thank).</div>
<div><br>
</div>
<div>
<div>We can also publish this on our websites. What do you
think about individual donate buttons (for where one
developer is responsible for a vehicle type)? I am happy
to do that, but would it be useful/helpful? I find that
people mostly hit donate when asking for support, so the
forums seem a good place for it.</div>
</div>
<div><br>
</div>
<div>To do that, we need a list of developers for each
vehicle type. Working off git logs, I’ve come up with the
following:</div>
<div><br>
</div>
<div>
<ul class="gmail-m_-4672449598992641952MailOutline">
<li>DBC: Mark W-J</li>
<li>DEMO: Mark W-J</li>
<li>Fiat 500e: Jakob Löw?</li>
<li>Kia e-Niro: Geir Øyvind Vælidalo?</li>
<li>Kia Soul EV: Geir Øyvind Vælidalo?</li>
<li>Mitsubishi i-Miev: Thomas Bergo, Juerg Walz,
KommyKT, Tamás Kovács?</li>
<li>Nissan Leaf: Tom Parker, Robin O’Leary, Anko Hanse?</li>
<li>OBDII: Mark W-J</li>
<li>Renault Twizy: Michael Balzer</li>
<li>Smart ED: Martin Graml, Thomas Heuer, Dimitrie78?</li>
<li>Think City: Hakon Markussen, Nikolay Shishkov?</li>
<li>Tesla Roadster: Mark W-J, Michael Stegen, Sonny Chen</li>
<li>Tesla Model S: Mark W-J</li>
<li>Volt/Ampera: Mark W-J, Michael Jochum?</li>
<li>Track: Mark W-J</li>
<li>ZEVA BMS: Paul Rensel?</li>
</ul>
<div><br>
</div>
<div>Could the developers of each of the above modules
help check that list and make sure I haven’t messed up?
Let me know if you would rather remain anonymous (I hope
not, as you deserve credit).</div>
<div><br>
</div>
<div>There is also the topic of overall contributors to
the project, but I think I can get the list of that from
the git logs and add somewhere in the manual.</div>
<div><br>
</div>
<div>Lastly, we have some ‘orphan’ vehicle projects in v2:
Kyburz, Zoe, Tazzari. If anybody has one of those cars
and wants to help, please let me know.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<blockquote type="cite">
<div>On 28 May 2019, at 3:14 AM, Michael Balzer <<a
href="mailto:dexter@expeedo.de" target="_blank"
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br
class="gmail-m_-4672449598992641952Apple-interchange-newline">
<div>
<div>The "projects" board really doesn't help in
organizing vehicle contributors or support. A
waste of time.<br>
<br>
I think pulling in changes unreviewed wouldn't be
good. We've got some inexperienced contributors
who can use a little review and guidance. We also
can see<br>
where the framework needs more documentation or
rules.<br>
<br>
I never felt any lack of ownership when working on
the system. In the beginning I worked on my own
fork and felt free to do whatever I wanted with
it. It was<br>
especially helpful being able to modify the
framework in my fork and include framework changes
into my pull requests. That made me feel being
part of the whole<br>
project from the beginning instead of just writing
a plugin.<br>
<br>
<blockquote type="cite">At the moment, the vehicle
modules are the most troublesome part of the
system. We get support calls / emails for these,
but no easy way to answer. I would really like
to find a way to ease and incentivise the
development of vehicle modules.<br>
</blockquote>
<br>
Btw, github forks have the "issues" menu disabled
only by default, that's just a config. If you
enable the issues menu on a fork, you're getting
your own issues<br>
database. But I wouldn't like to get user support
requests as "issues".<br>
<br>
I think the main issue here is routing vehicle
users to vehicle developers. It's not easy to
figure out who is currently in charge for a
vehicle adaption and<br>
how to contact them / file some issue or support
request.<br>
<br>
How about adding a vehicle contact section to the
wiki or main README.md and mirror that on our
websites? That way we're giving credit to
contributors and solve<br>
the routing problem.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
Am 27.05.19 um 17:24 schrieb Greg D.:<br>
<blockquote type="cite">Hi Mark,<br>
<br>
I think the process you used with me in the
development of the OBD2ECU<br>
process worked pretty well. I've always been
the owner of the code, but<br>
it was based on an initial template for system
services (CAN access, CLI<br>
processing, etc.) that you provided, and pull
requests got more or less<br>
of a review before the actual pull depending on
circumstance.<br>
<br>
I don't feel any less of an owner than if the
code were in a separate<br>
git repository. A lot of that is due to how you
manage the project, not<br>
where the bits are stored. In the end, it's all
compiled into one<br>
object module, and I don't think that part of
the process will (or<br>
should) change.<br>
<br>
Greg<br>
<br>
p.s. To the documentation task, please everyone
don't forget to update<br>
the table at the end of the user guide for what
metrics are available to<br>
the OBD2ECU translator, based on vehicle type.
I think we're missing<br>
whole columns for new vehicles, but haven't been
following the vehicle<br>
additions closely enough to know for sure..<br>
<br>
<br>
Mark Webb-Johnson wrote:<br>
<blockquote type="cite">I view them as modules,
not really standalone projects or libraries.
Kind of like all those modular components in
systems like GEM, HomeBridge, logstash, etc.
They won’t work outside their given ecosystem.<br>
<br>
Just trying to think of a way of making it
easier to get involved / write vehicle support
modules (and trying to encourage fitting in
with the existing framework, rather than
modifying it).<br>
<br>
Getting rid of having to merge pull requests
is one motivation, but it is really more
towards giving a sense of ownership to the
vehicle module maintainer. He/she can commit
as they work on the module, and both he/she
and the main project simply pull in whatever
they have at the time of build.<br>
<br>
At the moment, the vehicle modules are the
most troublesome part of the system. We get
support calls / emails for these, but no easy
way to answer. I would really like to find a
way to ease and incentivise the development of
vehicle modules.<br>
<br>
Regards, Mark.<br>
<br>
<blockquote type="cite">On 27 May 2019, at
7:55 AM, Stephen Casner <<a
href="mailto:casner@acm.org"
target="_blank" moz-do-not-send="true">casner@acm.org</a>>
wrote:<br>
<br>
In the cases I'm aware of, submodules are
independent building blocks<br>
used by other projects. Our vehicle modules
have many dependencies<br>
upon the core of the OVMS system. I'm not
sure if that works.<br>
<br>
Also, if you want to make standard releases
that support all the<br>
vehicles then you would be dependent upon
the separate project owners<br>
to get their submodules ready.<br>
<br>
I assume that your motivation for
considering this change is to avoid<br>
the load of be merging pull requests. I
acknowledge the extra work,<br>
but in my view that extra level of filtering
is often a good thing.<br>
<br>
-- Steve<br>
<br>
<br>
On Sun, 26 May 2019, Mark Webb-Johnson
wrote:<br>
<br>
<blockquote type="cite">Given that the
vehicle modules in v3 are pretty
independent, and don't seem to require any
changes to the core code to implement
(other than a Kconfig section, and a
sub-directory in 'components'), I'm
considering a structural change.<br>
<br>
The proposal is to make each vehicle an
independent GitHub repository, and to use
the git submodule functionality to bring
them in. The advantage there is that those
projects can be split off and maintained
by different people. Project owners,
looking after their own vehicle types,
could directly commit to their own vehicle
modules, without requiring this to be
centrally managed.<br>
<br>
What do people think? Is that a sensible
way of doing this?<br>
<br>
Regards, Mark.<br>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
<br>
-- <br>
Michael Balzer * Helkenberger Weg 9 * D-58256
Ennepetal<br>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br>
<br>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>