Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Company as maintainer

Archives

Contributors

Re: Company as maintainer

Re: Company as maintainer

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 one

    Would it be possible for us to do so?

    Thanks for your opinion!

    --

    Francesco Foresti
    Sicurpharma Srl
    by Francesco Foresti - 04:20 - 27 Oct 2022

    12 replies 12 replies

    • Re: Company as maintainer
      Hi, I think there are several interesting points in this conversation, as well as Jean-Charles' project which could be very useful in my opinion - keeping track of specific modules' improvement and/or bug reports would make our work quite easier.
      For example, knowing if a certain behavior has been fixed in a commit for the previous or next version of a module, and just migrating the commit instead of fixing it again.
      In general, as I mentioned in a previous email, I think it would be extremely convenient for PMs and devs alike to have some space where all things related to a module could be collected - PRs, known issues, general discussions, if module is or will be discontinued in future versions and why...

      But to keep discussion focus on maintainership: 

      Let's say Company A contracts Dev X to develop Module 1
      Module 1 is built on specifications provided by Company A, to address use cases from customers of Company A, and ultimately it's PM from Company A who designs how the module should work functionally (of course based on technical expertise and guidance from Dev X)

      If Dev X stops working with Company A, takes a sabbatical, leaves odoo development altogether or simply does not check notifications on email related to github account... 
      Are we sure that maintainership is better ensured by assigning the "maintainer" role to Dev X rather than Company A?

      Ultimately I don't think it's a bad idea to have them both.

      Francesco

      Il giorno dom 30 ott 2022 alle ore 01:37 Jean-Charles Drubay <notifications@odoo-community.org> ha scritto:
      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 base d 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.or g> 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

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe



      --

      Francesco Foresti
      Sicurpharma Srl
      +39 333 8123 790

      by Francesco Foresti - 02:46 - 31 Oct 2022
    • 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
    • Re: Company as maintainer
      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.
      by Pedro M. Baeza - 11:55 - 29 Oct 2022
    • Re: Company as maintainer
      That's nice to know all the pull requests from your company.

      But what I'm after is a mechanism to be notified when there are pull requests or issues opened against modules I'm interested in.
      GitHub per repo notifications are too coarse, that generate too much noise for many modules I don't care about.

      -sbi

      On Sat, Oct 29, 2022 at 11:36 AM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      What we do is to include in the pull request main comment `@Tecnativa` for later search for such pull requests, using `involves`. This is for example our current status:


      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 Stéphane Bidoul - 11:45 - 29 Oct 2022
    • Re: Company as maintainer
      What we do is to include in the pull request main comment `@Tecnativa` for later search for such pull requests, using `involves`. This is for example our current status:


      Regards.
      by Pedro M. Baeza - 11:26 - 29 Oct 2022