[Ovmsdev] Vehicle Sub-Modules

[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> 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
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> 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