Contributors mailing list archives


Re: Proposal to support small repos into the current OCA workflow

Open Source Integrators, Daniel Reis
- 19/06/2016 15:35:23
By default modules managed today in a "reference repo" would use the exact same workflow as today.

Remember that the fork where you have your migration change set is a "clone" of the original repo, and other people can propose commits there. You can even grant write access to trusted contributors.

Indeed, a version migration would be the perfect time to split a module into it's own small repo.

But I would avoid too much change for a first iteration of this workflow, so it would be wiser to first battle test the new workflow first, using new modules as subjects.


No dia 19/06/2016, às 15:53, robert rottermann <> escreveu:

Hi Daniel,
your proposal seems easy to follow.
A question:
        Can such an approach also be used on existing modules? So I would share 
a clone of say a mosule I am porting from v8 to v9?


On 19.06.2016 13:38, Daniel Reis wrote:
> 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: 
> 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
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe: