[NEW] Agile modules about project

[oscarolar]

Thanks @mileo

[nhomar]

I recommend do not extract everything in v9.0 we have plans of re-write dsome old features that can be uimproved-merged with new contract management system in v9 and/or new datamodel in tasks.

In v8.0 it is nice.

[mileo]

cc: @oscarolar

[rafaelbn]

I think we can use just "project" and we don't need to create a new one.

cc @dreispt

[oscarolar]

I think we can use just "project" and we don't need to create a new one.

👍

[mileo]

I forgot to speak, We opted for the initiative Vauxoo it is more modular.

We are evaluating some modifications in email templates:

• Use company images;
• Use company names;
  etc

[dreispt]

Yes, we should use OCA/project.

BTW, I'm thinking that we could use your repo to try the "satellite" repo approach. To allow that I already done some work with the CI tooling, but needs some improvements...

[dreispt]

@nhomar We should have a word on this from Vauxoo, since you're the authors.

[oscarolar]

@dreispt thanks, what is the "satellite repo approach"?, I'm sorry I don't fully understand what you meant.

[mileo]

@oscarolar Complete tread: https://odoo-community.org/groups/contributors-15/contributors-41966?mode=thread

Hello all,

I would like to propose to the OCA some guidelines to allow incorporating small repos into the OCA workflow.
I understand a "small repo" as a repository with a few closely related modules, or possibly a single module.

Currently the modules contributed to the OCA are organized in projects by topics/areas or interest: oca/event, oca/hr, oca/project, oca/web, etc.
This was a big improvement over the former organization, where all community modules were in a single repo, "addons-extra", that was very difficult to manage.

The current organization provides some important benefits:

• I can follow modules according to my areas of interest: I can choose to follow oca/hr and not to follow oca/website.
• I can be informed of the new modules in my areas of interest, that are proposed or get merged.

An approach to small repos is to have them as satellites to a reference integration project:
The existing repo, say OCA/hr, still concentrates all modules around a topic of interest, like today.
Satellite projects that are OCA ownedwould be automatically merged into their reference repo, probably through a nightly job.
Reference projects should not accept PRs for satellite managed modules.

The new additional workflow would look like this:

Proposing new repos to the OCA

To propose a new repo/modules for OCA inclusion, create a repo, owned by yourself.
Then make a WIP PR for it against the OCA reference repo.
This announces your work to other community members, and allows you to discuss and have feedback on your code.

GitHub should automatically notify further activity to the followers of the reference repo
The documentation state that "GitHub automatically delivers notifications when a user commits to a pull request that you're subscribed to".
See more at: https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/

When the new repo is mature and approved for OCA inclusion, instead of merging the PR we change the repo's owner to the OCA.
People interest in further proposed changes to those modules should follow the satellite repo.

Further pull requests on those modules must be done against the satellite repo, and not the reference repo.
Changes merged into the satellite repo are automatically (nightly?) merged in the reference repo.
So the followers of the reference repo can be notified of the changes done there.

That's it.

There are quite a few details and technical issues to solve in order to put this in practice.
I'm not detailing now these problems, and possible solutions, since I would prefer to focus on the big picture for now.

Best regards
Daniel Reis

[moylop260]

+1

[elicoidal]

👍

[dreispt]

@mileo
The straightforward way is extract each module and make a PR for OCA/project.
The daring way is to volunteer using your repo as an experiment for the "satellite repo" approach, with all the inconveniences an experimentation can bring. But I would support you as much as I can.

[mileo]

@dreispt
Let's do de daring way!
Do you want access to the repository?
Anything else I can help you, feel free to contact me at https://gitter.im/mileo

[dreispt]

@mileo Great! Write access can be helpful but it's not strictly needed - I can always use PRs.
Let me do some needed work on OCA/maintainer-quality-tools and I'll get back to you.

[rvalyi]

Yeah, I also think agile project can be a good conceptual unit to be extracted as a separate repo instead of keeping bloating the current project repo into something not manageable. In this case it also has some origin coherence, making it also easier to administrate as a new repo with Vauxoo's people.

[dreispt]

@rvalyi Yes, I agree that it makes sense for multiple reasons.
To be clear, in the end this repo will move under the OCA, by changing it's owner.
At that point it will be as controlled as any other OCA repo.

In a nutshell, the MQT changes needed are:

a) This repo Travis builds will be made after locally merging the integration repo on it (OCA/project in this case), so that we run integrated tests.
b) The same thing applies for OCA/project buils - PRs and tests there will be performed after the main repo and all its satellites are merged.

[astirpe]

Since the repository https://github.com/OCA/project-agile was created last November, I think that this issue can be closed.

[dreispt]

For the record: allowing a workflow similar to the one described above is back on the table. I'm working on a new proposal for that.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.