- Mailing Lists
- Contributors
- Re: Company as maintainer
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: Company as maintainer
Hi,
I share the same observation more and more: there is a need to track/manage modules instead of repositories.
Going in this direction I started to work on this topic which started around OpenUpgrade only at first until I realized that this need was broader than OpenUpgrade only:
I have prepared a prototype to share the information per module and which can be tested here https://oca-cm-15.komit.link
The Issues and PRs are linked to the module based on the name of the Issues/PRs so at this stage it's not reliable.
But naming conventions could be enforced by github checks I guess, at least for the PRs.
Adding a notification mechanism should not be complicated.
I am currently working on a v2 of the prototype.
I am open to sharing the code, which I already did upon request.
I am also open to discussions.
| Best regards, Jean-Charles |
On Sat, Oct 29, 2022 at 4:57 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
I'm afraid I don't have a solution for that. I'm subscribed to everything... and yes, lots of noise. But it also serves for having a whole picture, as "what are the modules I am interested in?" Maybe a new module arises over a feature I want.I use my self-called "5 seconds rule" for dealing with the huge amount of notifications: 5 seconds to decide if to discard it, answer immediately if it takes less than a minute, which can be my distraction window, or let it in my inbox for a later and more calm answer. This allows me to be reactive enough as well as not requiring too much time.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Jean-Charles Drubay - 01:35 - 30 Oct 2022
Reference
-
Company as maintainer
Hello,since we have several devs working on modules developed by our company in OCA, we'd like to attribute the role of "maintainer" of such modules to a company github account in order to centralize:- notifications about changes to modules we have originally developed- questions and communications about the aforementioned modules- merging of minor changes such as this oneWould it be possible for us to do so?Thanks for your opinion!--Francesco ForestiSicurpharma Srl
by Francesco Foresti - 04:20 - 27 Oct 2022