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.
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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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
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@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@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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark,
thanks for the structuring work.
I can't see any subscribe button / function in the forum though, and find no option in my account to enable such. Is something wrong with my account?
I suggest vehicle maintainers get forum admin rights for their sections, so they can add sticky/locked info threads and edit posts.
Being able to add vehicle maintainer donation info would be nice. Maybe with admin rights that can basically be done by the maintainer using a sticky thread as well?
Regards, Michael
Am 30.05.19 um 08:42 schrieb Mark Webb-Johnson:
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@expeedo.de <mailto:dexter@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@acm.org <mailto:casner@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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
I can't see any subscribe button / function in the forum though, and find no option in my account to enable such. Is something wrong with my account?
Yes. Mea culpa. I fixed the permissions (for everyone, not just you), and now should be ok.
I suggest vehicle maintainers get forum admin rights for their sections, so they can add sticky/locked info threads and edit posts.
Being able to add vehicle maintainer donation info would be nice. Maybe with admin rights that can basically be done by the maintainer using a sticky thread as well?
I will try to add this. I think it needs another module to add this moderator level functionality. It is certainly a good idea.
Regards, Mark.
On 30 May 2019, at 3:31 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
thanks for the structuring work.
I can't see any subscribe button / function in the forum though, and find no option in my account to enable such. Is something wrong with my account?
I suggest vehicle maintainers get forum admin rights for their sections, so they can add sticky/locked info threads and edit posts.
Being able to add vehicle maintainer donation info would be nice. Maybe with admin rights that can basically be done by the maintainer using a sticky thread as well?
Regards, Michael
Am 30.05.19 um 08:42 schrieb Mark Webb-Johnson:
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@expeedo.de <mailto:dexter@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@acm.org <mailto:casner@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.
-- SteveOn 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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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 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@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@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.
-- SteveOn 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@webb-johnson.net <mailto:mark@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@expeedo.de <mailto:dexter@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@acm.org <mailto:casner@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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
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 ?
Not really concerned about the Apps, more the 12V battery :-) I think until we have good deep sleep support, this might be dangerous. There is nothing in the framework to limit this to cars (that is why we talk about ‘vehicle’ more than ‘cars’). An early user of OVMS put it in a fleet of buses.
About restructuring/refreshing, have you plan or think about upgrade mailman 2.1 to mailman 3.x with something like hyperkitty ?
Not high up on my radar. Last I looked, mailman 2.1 -> 3.x upgrade was ‘buggy’ (their term, not mine). Has that changed? If it is a relatively simple upgrade path, I am happy to do it.
Regards, Mark.
On 30 May 2019, at 3:58 PM, Olivier <ogrums@gmail.com> wrote:
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@webb-johnson.net <mailto:mark@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@expeedo.de <mailto:dexter@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@acm.org <mailto:casner@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.
-- SteveOn 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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2019-05-29 23:24, Mark Webb-Johnson wrote:
About restructuring/refreshing, have you plan or think about upgrade mailman 2.1 to mailman 3.x with something like hyperkitty ?
Not high up on my radar. Last I looked, mailman 2.1 -> 3.x upgrade was ‘buggy’ (their term, not mine). Has that changed? If it is a relatively simple upgrade path, I am happy to do it.
I run mailman a few places and recently looked into upgrading. It's definitely a mess. It's broken up into a bunch of different python modules and pulls in an impressive number of non-base modules. It uses django which is great but they don't provide a working django config, just a reference. After a fair amount of effort in setting it up I gave up.
Funny story. Early in my python career I went to pycon with a friend who wanted to stay after and do sprints for a few days. When ended up working on mailman3.
This was in 2005 and as far as I can tell it still isn't to the point of being very usable.
Craig
participants (6)
-
Craig Leres -
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Olivier -
Stephen Casner