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
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 28/08/2015 20:50:23 
>
> 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.
>
Until now every modification affecting existing repos has always
discussed with contributors, and I was taken by surprise by the
unexpected change.
I apologize for any excesses.
But I think we're past that, so let's move on.


> 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.
>
I understand you were executing, the way you thought best, a board
decision. Nothing personal here.
My main concern here is that IMO the board was not supposed to make
these decisions for existing projects.
I fear there may be a broader governance issue here, but that's a
different discussion to have in a different place (away from the trolls).


> 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).
The problem is that it makes the repo Service Management specific when
it was not.
And in the process creates a gap for Project Management modules - we now
have no place for them.
I'm unsure of what is the scope for the vertical-service repo (and what
the board perceived as the project-service repo scope).


>
> 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.
>
Agreed.
That's why it's important to discuss, gather several opinions, and then
decide the best compromise.

>
> 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.
>
I feel that my arguments are still not addressed.
I'm summarizing them:

1) "project-service" scope is Project *and* Service Management features,
not service management.
2) This is confirmed by it's current modules and PRs: the vast majority
is not service management specific.
3) The "vertical-service" name is misleading and not suitable for
project management features.

So, with all the feedback given until now my current best proposals are:

- I agree that OCA/project-service can be a confusing name, so I suggest
to rename it to "OCA/project". This is closer to the de facto convention
used in the other OCA repos.
- To not create a service management dedicated repo
(OCA/vertical-service or OCA/service). While I see value in that idea, I
don't think it's a priority. right now.


Regards
--Daniel

Reference