[Ovmsdev] Vehicle Sub-Modules
Michael Balzer
dexter at expeedo.de
Thu May 30 16:07:44 HKT 2019
Olivier,
neither module nor App limit the vehicle type to cars. The framework fits all types of vehicles.
App support for a new vehicle is normally just adding the images, plus maybe minor logic changes for the fast charging detection.
Regards,
Michael
Am 30.05.19 um 09:58 schrieb Olivier:
> Hello Mark,
>
> 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 ?
>
> About restructuring/refreshing, have you plan or think about upgrade mailman 2.1 to mailman 3.x with something like hyperkitty ?
>
> regards, Olivier
>
> Le jeu. 30 mai 2019 à 08:49, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> a écrit :
>
> Michael, and others, thanks for your feedback.
>
> 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.
>
> I have restructured the forums on www.openvehicles.com <http://www.openvehicles.com> 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.
>
> 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).
>
> 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.
>
> 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).
>
> 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.
>
> To do that, we need a list of developers for each vehicle type. Working off git logs, I’ve come up with the following:
>
> * DBC: Mark W-J
> * DEMO: Mark W-J
> * Fiat 500e: Jakob Löw?
> * Kia e-Niro: Geir Øyvind Vælidalo?
> * Kia Soul EV: Geir Øyvind Vælidalo?
> * Mitsubishi i-Miev: Thomas Bergo, Juerg Walz, KommyKT, Tamás Kovács?
> * Nissan Leaf: Tom Parker, Robin O’Leary, Anko Hanse?
> * OBDII: Mark W-J
> * Renault Twizy: Michael Balzer
> * Smart ED: Martin Graml, Thomas Heuer, Dimitrie78?
> * Think City: Hakon Markussen, Nikolay Shishkov?
> * Tesla Roadster: Mark W-J, Michael Stegen, Sonny Chen
> * Tesla Model S: Mark W-J
> * Volt/Ampera: Mark W-J, Michael Jochum?
> * Track: Mark W-J
> * ZEVA BMS: Paul Rensel?
>
>
> 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).
>
> 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.
>
> 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.
>
> Regards, Mark.
>
>> On 28 May 2019, at 3:14 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> The "projects" board really doesn't help in organizing vehicle contributors or support. A waste of time.
>>
>> 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
>> where the framework needs more documentation or rules.
>>
>> 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
>> 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
>> project from the beginning instead of just writing a plugin.
>>
>>> 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.
>>
>> 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
>> database. But I wouldn't like to get user support requests as "issues".
>>
>> 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
>> how to contact them / file some issue or support request.
>>
>> 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
>> the routing problem.
>>
>> Regards,
>> Michael
>>
>>
>> Am 27.05.19 um 17:24 schrieb Greg D.:
>>> Hi Mark,
>>>
>>> I think the process you used with me in the development of the OBD2ECU
>>> process worked pretty well. I've always been the owner of the code, but
>>> it was based on an initial template for system services (CAN access, CLI
>>> processing, etc.) that you provided, and pull requests got more or less
>>> of a review before the actual pull depending on circumstance.
>>>
>>> I don't feel any less of an owner than if the code were in a separate
>>> git repository. A lot of that is due to how you manage the project, not
>>> where the bits are stored. In the end, it's all compiled into one
>>> object module, and I don't think that part of the process will (or
>>> should) change.
>>>
>>> Greg
>>>
>>> p.s. To the documentation task, please everyone don't forget to update
>>> the table at the end of the user guide for what metrics are available to
>>> the OBD2ECU translator, based on vehicle type. I think we're missing
>>> whole columns for new vehicles, but haven't been following the vehicle
>>> additions closely enough to know for sure..
>>>
>>>
>>> Mark Webb-Johnson wrote:
>>>> 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.
>>>>
>>>> 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).
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 27 May 2019, at 7:55 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>
>>>>> In the cases I'm aware of, submodules are independent building blocks
>>>>> used by other projects. Our vehicle modules have many dependencies
>>>>> upon the core of the OVMS system. I'm not sure if that works.
>>>>>
>>>>> Also, if you want to make standard releases that support all the
>>>>> vehicles then you would be dependent upon the separate project owners
>>>>> to get their submodules ready.
>>>>>
>>>>> I assume that your motivation for considering this change is to avoid
>>>>> the load of be merging pull requests. I acknowledge the extra work,
>>>>> but in my view that extra level of filtering is often a good thing.
>>>>>
>>>>> -- Steve
>>>>>
>>>>>
>>>>> On Sun, 26 May 2019, Mark Webb-Johnson wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> What do people think? Is that a sensible way of doing this?
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> _______________________________________________
>>>> 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 <mailto: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 <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/20190530/1a5efa59/attachment.htm>
More information about the OvmsDev
mailing list