Contributors mailing list archives
Re: Proposal to support small repos into the current OCA workflowby
Nice! As announced: evolutionary! + 1
Just a tiny comment: Would it be bad to suggest a OCA-dev organization? This prevent's cluttering the actual nicly organized repos. Yet this might be a technical detail and you already conceived it that way.
And another nice feature about this: It facilitates unburocratic collaboration, which is something imo very important to the great majority of not-yet-regular-contributers. Yet, by transferring ownership, quality control can be handed over to a more rigid regime managed by the PSC Members. It would be even possible to delegate/keep some responsibility (commiting rights) with the main commiter, if he is trustworthy. The main commiter of a functionality is often derply involved and has already natural ownership of his code. This is to be conserved. However, this decision could be made on a per case basis by PSC. Just the right grain of flexibility!
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.
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.
ThinkOpen Solutions Portugal, Daniel Reis