Contributors mailing list archives
Re: Proposal to support small repos into the current OCA workflowby
Open Source Integrators, Daniel Reis
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 <firstname.lastname@example.org> escreveu:
Hi Daniel, thanks. 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? robert 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: > 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 > > _______________________________________________ > Mailing-List: http://odoo-community.org/groups/contributors-15 > Post to: mailto:email@example.com > Unsubscribe: http://odoo-community.org/groups?unsubscribe >
Open Source Integrators, Daniel Reis