1. Mailing Lists
  2. Contributors
  3. Re: Renaming OCA/project-service to OCA/vertical-service

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Renaming OCA/project-service to OCA/vertical-service

Re: Renaming OCA/project-service to OCA/vertical-service

Avatar

Re: Renaming OCA/project-service to OCA/vertical-service

by
Tecnativa. S. L., Pedro M. Baeza
- 28/08/2015 19:24:40
Hi, Daniel (and all),

I apologize if we have made you upset, but what started as an administrative task has grown to something more, and we won't intend that at first instance.

The decision of renaming the repo was something done for ease users to recognize the content of the repo, due to the description of it already includes that scope (you already remembered that previously, contract and project-service were joined). As Github makes this renaming transparent, redirecting all requests from the old name to the new one, there's nothing more to do. And all of this comes because there has been a request for including some contract-related modules.

This decision has been done in a quick way and without consulting for 2 main reasons:
  • The scope of the repo hasn't changed.
  • There is a component that nobody outside from the board values: the administrative work that a new repo means. Eric can say what is this when he made it for the first time for l10n-china.
Now, what it seems to hurt the most is the chosen name: vertical-service. Maybe we miss here your (contributors) opinion, that could be valuable, but it was done in the same sense: let's put a general name that doesn't restrict us in the future. Then we can discuss when PRs come, if we need to split across repositories on each version (as we do when merging contract and project-service).

Pleople, think on one thing: we are dealing constantly with the imperfection: there's no perfect classification, because in the ERP all is connected, integrated, overlapped... so repos are the "best compromise" to handle things in a manageable way, but we all have faced incongruences in modules locations, change of mind about repo creation/deletion, etc, because the "algorithm to decide" has so many side effects that ourselves apply it differently over time and over cases.

@Raphäel, the 1 repo = 1 module can alleviate this situation, but then the discussion will be moved to the tags applied to each repo, and you know the technical (and administrative) challenges that this architecture implies, but this solution is also on the table, you know by the other thread.

Said that, hoping that at least you understand our position, we don't want that you save this bitter taste about this topic, so if you think there's a more appropiate name for the repo, we can handle another renaming. We can even create another repo in the spirit of pleasing if enough arguments are given, but I have argued against it in this mail.

Regards

2015-08-28 18:07 GMT+02:00 Daniel Reis <dgreis@sapo.pt>:
> just a word to say this illustrate again the dead end of trying to
> manage several modules in the same branch. IMHO the only soultion is
> indeed one module = 1 repo and have eventually a list of official OCA
> semantic tags to classify the modules. There will always be border
> line modules, cross dependencies and whil we can probably overcome
> this specific issue, such issues will only arrise more and more often.
>
That's under discussion in the v9 migration thread. I posted my concerns
about the collaboration workflow and until now no convincing arguments
were proposed. For that to be viable we first need solutions to:
1) Collaborate (new modules, PRs)
2) Steering (Issues, cross compatibility, feature overlapping, roadmaps)
3) Technical migration (dependency discovery, git details)

> Also today, the OCA isn't yet really visible commercially speaking.
> That means people who take care of managing it such as PSC, have a
> growing burden, as number of modules and PR's grow with little
> incentive for it. I think it's important to keep a good balance and
> keep the OCA scope inside something doable. That is the OCA won't
> manage all Odoo modules of the world and this is very fine. I think
> this also means we should quickly establish a list of stable central
> modules for which a high level of security/burocracy is required and
> by opposition have a lot more flexible rules for maturing satellite
> modules for which there is not enough experienced active contributors
> anyway.
>
Essentially you propose OCA to reduce it's scope to only a module shortlist.
But the OCA is a collection of hundreds of "ant" modules, and I'm afraid
no one can elect a list of "killer" modules to oversee.
IMO there is a lot of low quality code out there, even from experienced
Odoo partners (throw the first rock who never wrote a "bad module").
The OCA provides a safe place where we can have some quality assurance.

But maybe there is some middle ground: again an "incubator" space could
be an interesting experiment - with OCA tooling and processes, but repos
not controlled by OCA.


> That being said kudos for the hard work again.

Thank you for moving off the topic ;-)

--Daniel

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


Reference