Giter Site home page Giter Site logo

oca / maintainer-tools Goto Github PK

View Code? Open in Web Editor NEW
264.0 77.0 445.0 1.14 MB

Odoo Maintainers Tools & conventions for OCA members which evaluate and maintain repositories.

License: GNU Affero General Public License v3.0

Python 92.75% HTML 2.27% CSS 0.08% JavaScript 2.19% Shell 0.66% Jinja 2.05%

maintainer-tools's Introduction

CI Coverage Status

OCA Maintainers Tools

Installation

$ git clone [email protected]:OCA/maintainer-tools.git
$ cd maintainer-tools
$ virtualenv env
$ . env/bin/activate
$ python setup.py install

Alternatively if using pipx.

$ pipx install oca-maintainers-tools@git+https://github.com/OCA/maintainer-tools.git

OCA repositories tools

These tools are mostly for maintenance purpose only. They are used by OCA maintainers to address common operations across all repos.

Prerequisite

Github authentication uses a token, that must be previously created on Github, at Settings > Developer settings > Personal access tokens.

Set and store the token to be used for Github auth using:

$ oca-github-login

Alternatively, the token can be set on the GITHUB_TOKEN environment variable.

Sync team users from community.odoo.com to GitHub teams

Goal: members of the teams should never be added directly on GitHub. They should be added on https://community.odoo.com. This script will sync all the teams from Odoo to GitHub.

Prerequisites:

  • Your odoo user must have read access to the projects and users;
  • The partners on odoo must have their GitHub login set otherwise they won't be added in the GitHub teams;
  • Your GitHub user must have owners rights on the OCA organization to be able to add or remove members;
  • The odoo project must have the same name than the GitHub teams.

Run the script in "dry-run" mode:

$ oca-copy-maintainers --dry-run

Apply the changes on GitHub:

$ oca-copy-maintainers

The first time it runs, it will ask your odoo's username and password. You may store them using the --store option, but watch out: the password is stored in clear text.

Set labels on OCA repository on GitHub

Set standardized labels to ease the issue workflow on all repositories with same colors. This tools will also warn you what are the specific labels on some repository

$ oca-set-repo-labels

Clone all OCA repositories

The script oca-clone-everything can be used to clone all the OCA projects: create a fresh directory, use oca-github-login (or copy oca.cfg from a place where you've already logged in) and run oca-clone-everything.

The script will create a clone for all the OCA projects registered on github. For projects already cloned, it run git fetch --all to get the latest versions.

If you pass the --organization-remotes <comma-separated-list> option, the script will also add remotes for the listed accounts, and run git fetch to get the source code from these forks. For instance:

$ oca-clone-everything --organization-remotes yourlogin,otherlogin

will create two remotes, in addition to the default origin, called yourlogin and otherlogin, respectively referencing [email protected]:yourlogin/projectname and [email protected]:otherlogin/projectname and fetch these remotes, for all the OCA projects. It does not matter whether the forks exist on github or not, and you can create them later.

TIP to update branch in shell at once: ls | xargs -I % git -C % pull origin branch_number

Quality tools

These tools are meant to be used both by repo maintainers and contributors. You can leverage them to give more quality to your modules and to respect OCA guidelines.

README generator

To provide high quality README for our modules we generate them automatically. The sections of the final README are organized in fragments. They must be put inside a readme folder respecting [this structure|./readme].

eg. To generate the final README for the module auth_keycloak:

$ oca-gen-addon-readme --repo-name=server-auth --branch=10.0 --addon-dir=auth_keycloak

The result will be a fully PyPI compliant README.rst in the root of your module.

You may also use this script for your own repositories by specifying this additional argument --org-name=myorganisation

Changelog generator using towncrier

To facilitate the generation of the changelog of addons, we have a small wrapper around towncrier. For example, this will update HISTORY.rst for mis_builder and mis_builder_budget with the version found in their manifest:

$ oca-towncrier --repo=mis-builder --addon-dir=mis_builder --addon-dir=mis_builder_budget --commit

Icon generator

To provide an icon for our modules we generate them automatically.

To generate the icon for the module auth_keycloak:

$ oca-gen-addon-icon --addon-dir=auth_keycloak

A custom icon can be added using the --src-icon argument:

$ oca-gen-addon-icon --addon-dir=auth_keycloak --src-icon=/path/to/custom/icon.png

Developers

As a developer, you want to launch the scripts without installing the egg.

$ git clone [email protected]:OCA/maintainer-tools.git
$ cd maintainer-tools
$ virtualenv env
$ . env/bin/activate
$ pip install -e .

Run tests

$ tox  # all tests for all python versions
$ tox -e py27  # python 2.7
$ tox -- -k readme -v  # run tests containing 'readme' in their name, verbose

Set the client token to use for Github authentication

$ python -m tools.github_login

Run a script

$ python -m tools.copy_maintainers

You can use the GITHUB_TOKEN environment variable to specify the token

$ GITHUB_TOKEN=xxx python -m tools.copy_maintainers

Integration with pre-commit

In any addons repo, you can use these pre-commit hooks:

# .pre-commit-config.yaml file
repos:
  - repo: https://github.com/OCA/maintainer-tools
    rev: master # This is just an example; you must use a tag/commit instead!
    hooks:
      # Use each script's `--help` to understand the args
      - id: oca-gen-addon-readme
        args:
          - --addons-dir=.
          - --org-name=OCA
          - --repo-name=server-tools
          - --branch=13.0

      # This job could easily produce conflicts when it runs on every commit,
      # so it's added as a manual job. If you automate it, beware.
      # See https://pre-commit.com/#confining-hooks-to-run-at-certain-stages
      - id: oca-gen-addons-table
        stages: [manual]

      - id: oca-gen-addon-icon
        args:
          - --addons-dir=.

maintainer-tools's People

Contributors

bealdav avatar bwrsandman avatar dreispt avatar elbati avatar elicoidal avatar guewen avatar gurneyalex avatar hbrunn avatar jcdrubay avatar jgrandguillaume avatar jordibforgeflow avatar lasley avatar legalsylvain avatar lepistone avatar lmignon avatar max3903 avatar miquelrforgeflow avatar moylop260 avatar nbessi avatar nhomar avatar obulkin avatar os-ia avatar pedrobaeza avatar remi-filament avatar rousseldenis avatar sbidoul avatar simahawk avatar tafaru avatar yajo avatar yvaucher avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

maintainer-tools's Issues

Defining list of labels

Hello,

It is time to standardize a bit our tags to ease the review process.

As far as I know labels can only be created by owners

I already see some duplicates for same use like:

on hold (l10n_switzerland) and work in progress (account-financial-tools, others)

I suggest to make a complete list on maintainers tools to be copied on all repositories

What is mainly missing on repositories are the following labels:

For work in progress I saw red, lightblue and yellow. I suggest an other color.

This could help:
https://developer.github.com/v3/issues/labels/

change the objective sentence

I would like to move from:
This module was written to extend the functionality of ... to support ... and allow you to ...

to
This module extends the functionality of ... to support ... and allow you to ...

(more direct and "was written" is awkward while not bringing any information)

Merge commit: s/bzr/git + question

Current Text

While making the merge, please respect the author using the --author option when committing. The author is found using the bzr log command.

Suggestion

  • bzr log should be replaced by git log

Question

  • Is it necessary to use the --author? because I imagine the original commit will be merged with the author.

Make this a package installable opensourcing in the right way.

Introduction.

In my opinion this repository should be a package correctly opensourced in order to be able to even declare it in pypi.

Why?

We the people that mantain things like almost everything automated and honestly not have a correct installation of this allow only people super-experienced understand how it works.

IMHO if we try something like:

sudo pip install maintainer-tools
Read the manual.
Have a list of shell commands correctly finished.

Then I think it can help to _new people_ to use this as a set of "Standards Tools" starting from scratch, and expend less time themselves fixing things of Form and doing more things of Value on their PR.

Saving time of reviewers and big teams to improve them development time.

My proposal:

  1. Follow this guidelines for this repository in order to "Opensource our tools in the right way."

If the proposal is approved, I can set a roadmap here to start the job.

Thanks in advance.

Cannot login via oca-github-login

Milestone (Odoo version)

Module(s)

oca-github-login

Steps to reproduce

eric@eric--XPS-15Z:/CVS/oca$ oca-github-login elicoidal
Password for elicoidal:
The 'OCA (odoo community association) Maintainers Tools' token already exists. You will find it at https://github.com/settings/applications and can revoke it or set the token manually in the configuration file.
eric@eric--XPS-15Z:
/CVS/oca$ ls
maintainer-tools oca.cfg
eric@eric--XPS-15Z:/CVS/oca$ oca-clone-everything
No token has been generated for this script. Please run 'oca-github-login'.
eric@eric--XPS-15Z:
/CVS/oca$ rm oca.cfg
eric@eric--XPS-15Z:/CVS/oca$ ls
maintainer-tools
eric@eric--XPS-15Z:
/CVS/oca$ oca-github-login elicoidal
Password for elicoidal:
The 'OCA (odoo community association) Maintainers Tools' token already exists. You will find it at https://github.com/settings/applications and can revoke it or set the token manually in the configuration file.
eric@eric--XPS-15Z:/CVS/oca$ ls
maintainer-tools oca.cfg
eric@eric--XPS-15Z:
/CVS/oca$ oca-clone-everything
No token has been generated for this script. Please run 'oca-github-login'.

Current behavior

cannot clone oca repository due to the login behavior

Expected behavior

OCA Github Bot

Bountysource

Goal

  • Develop a bot that will help the review process for the maintainer, help newcomers, close too old PRs, etc..

Current troubles

  • Time to merge, # of PR increases
    • โ†’ Generates frustration among new contributors
    • โ†’ Discouraging contributors
  • Travis is not always green
    • Lots of time taken to make Travis green
    • Not easy for newcomers to make it green
  • Merging rules might be too strict ?
  • PSC might have the right to merge faster? Yes, PSC can decide if merge something although some guidelines are not met.
  • Optimistic Merging (OM) instead of Pessimistic Merging (PM)?
  • Difference between new modules and existing modules ?
  • Different maturity levels in the same projects/repo in term of quality, reliability, usage
  • Different level of maintenance among them (some are very active, others abandoned)
  • Different levels of responsibility from the PSC

Wanted Features

Version 1

  • Tag pull requests with "New contributor" for people with less than 3 PR within the OCA repos
  • Close and comment ("Please re-open if necessary") every PR older than 6 months without comments
  • Tag and comment if the pull request is ready to be merged (2 approvals, 5 days, green CI)

Later

  • Tag โ€œnew module proposalโ€ or โ€œimprovements on existingโ€
  • Post message in case of:
    • Travis red -> how to solve
    • Newcomers -> Say hello, thanks you, where to look for help + pointer to doc or relevant link

Resources

Use : https://github.com/facebook/mention-bot
Note this module already interact with github and odoo https://github.com/legalsylvain/oca-custom

README.rst maintainability

Milestone (Odoo version)

  • at least from v10

Module(s)

  • all modules

Steps to reproduce

  1. Write README.rst according to template
  2. all README looks like template at the time of the merge, not last template

Current behavior

README.rst is statically generated and is never up to date. Painful / frustrated for readers/reviewers/developers (waste of time)
Personally I limit module contributions to oca because of that. Create a module with README template is ~ easy but not maintain it.

Expected behavior

How

  • README is a mix of static content (or depending on branch name/milestone) and specific content
  • We could automate merge of these data.
  • By add some keys to __manifest__.py for specific content: usage, configuration, roadmap, issues, etc.
  • script update README content periodically

What do you think ?

Proposal: Improve Contributing Guidelines and OCA website

Hello:

First of all thanks to all OCA by this hardwork.

I would like to propose a change in:

I think every contributor must read the CONTRIBUTING.md and defining the same structure in the tiitle of issues and PRs will help us a lot when: (1) someone searching for a issue that already exists (2) reviewing issues or PRs. It will make our life better.

  1. Version: it's writed, all issues and PRs tittles must begin with versiรณn like [8.0][9.0]
  2. Why?:
    • [ADD]: add new module to the project
    • [FIX]: fix a module in the project
    • [IMP]: improve the functionality of the module
  3. Which? Shows the name of the module [name_of_the_module]
  4. What? Description of the module.

In website /bugs:

  1. Describe your bug

Before creating a new issue in the Github repository, make sure it is not already reported by browsing the list.
You can seach by module's name in the tittle

Then, create a new issue, with the following information:

Then, create a new issue, you have two ways:

  • Every module has in the README a Bugtracker which will open you a issue in Github ready to describe

captura

captura1

  • Create a new issue manually wit the following information:
a title: enter the Odoo version between bracket and the last line of the error message 

a tittle: enter the Odoo version, why and module's name, each one between braket and the las line of the error message as i the example:
-Version: [8.0]
-Why: [BUG]
-Module's name: [website_signup_legal_page_required]
-Description: Internal Server Error when signing up

a description : describe the bug
the steps to reproduce
the result you experienced with the complete error message
the result you expected
module: website_signup_legal_page_required
version: 8.0
**Steps to reproduce**
- ...
**Current behavior**
**Expected behavior**

Other contributors may ask you for further information to qualify your bug before working on a fix. > Make sure to answer them. If you have the skills, please code the fix and share it.

In website /code:

  1. Push your code and create a pull request

Please set tittle of PR like:

  1. Version: it's writed, all issues and PRs tittles must begin with versiรณn like [8.0][9.0]
  2. Why?:
    • [ADD]: add new module to the project
    • [FIX]: fix a module in the project
    • [IMP]: improve the functionality of the module
  3. Which? Shows the name of the module [name_of_the_module]
  4. What? Description of the module.

Once you committed your changes in your local branch, you can publish it by pushing it to your Github repository.
Read our FAQ to determine the best open source license for your module.
Once your branch is on Github, you can create a pull request against the OCA branch

Let me know

Thanks

Packaging

Write a script to be triggered during a merge:

  • check if version has changed in the manifest of all the modules of the branch (better detection could be implemented later)
  • generate a setup.py and an egg file for each modified module, using the dependencies and extra-dependencies from the module manifest
  • generate a deb package (some doc: https://pypi.python.org/pypi/stdeb#bdist-deb-distutils-command)
  • generate a rpm package (https://docs.python.org/2/distutils/builtdist.html)
  • publish the wheel on Pypi (with setuptools)
  • publish the deb on deb.odoo-community.org
  • publish the rpm on rpm.odoo-community.org

Tests

  • use pip, yum or apt-get to deploy an instance

[RFC] Contribution: Merger Commit Squashing

We have all likely noticed these awesome new Github Squash and merge & Rebase and merge options, and I think we all agree they are freaking awesome.

I have recently run into some instances of these features being used in ways that are detrimental, and feel that we need to start defining some rules on how we use these. Please see the following for an example of why I am bringing this up:

Another thing with squash & merge is that it destroys any cryptographic signatures that may have been purposefully applied by the committer. Due to this, I prefer to squash my own commits in order to maintain integrity of my commit.

That said, I'm sure this isn't the case with everybody. I'm insanely OCD when it comes to this sort of this, mainly because I've been put in the position many times where someone has made a mistake on a squash/rebase, but it's linked to me because of the wizardry that is timeline editing.

I'm not sure how to solve this problem of preference vs necessity though. The squash and merge is so incredibly helpful when dealing with newer contributors, because the whole squashing thing is a definite detractor in terms of contribution. But how do we apply this in some sort of manor that still allows the people that do want to squash to do so?

Github labels for non maintainers users

The problem is well describded here:
neovim/neovim#1409

It would be great to let people label them-selves their PR when it needs review or when they consider it to be WIP.

Here is path we could follow by using a bot to auto-assign labels depending on PR titles:
neovim/bot-ci#28

To note, actually labels are automatically removed when a PR is merged. This is done by Waffle.io

Feedback hyperlink for issue report

Currently, for module template edition has a minimal issue, I think. It is hard (and sometimes confusing) to locate all the to-be-replaced fields when creating a new module, the line below shows the current feedback link

`here <https://github.com/OCA/{project_repo}/issues/new?body=module:%20{module_name}%0Aversion:%20{version}%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

As reStructuredText doesn't keep line break done in raw text and it will be rendered as expected to be. So I suggest something like

`here <https://github.com/OCA/
{project_repo}
/issues/new?body=module:%20
{module_name}
%0Aversion:%20
{version}
%0A%0A**Steps%20to%20reproduce**%0A%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Convention for the method name of new API onchanges

I have came across a problem that leads me to write this issue to discuss with the contributors: new API allows to set multiple onchange without the need of calling super to respect inheritance chain. This overcomes a past limitation with old-style view onchanges (the other is the no need of declaring parameters for accessing the values).

But this only happens, if the name of the method is different on each model overwriting!! I think this is a limitation in the way ORM handles pointers to these methods, only storing the name of the method in a list or a dictionary. Maybe @rco-odoo can give us a more detailed explanation or even a possible solution as a patch.

In the case this can't be solved, as we all tend to normalize the onchange method to onchange_<field_name>, which can lead to incompatible modules that both use the onchange with the same method name, one possible solution is to have as convention to name the methods as:

def onchange_<field_name>_<module_name>

This way, onchange methods will never collide and all will be executed.

What do you think?

PROPOSAL: automate linting pre-commit or server hooks approach

UPDATE: If interested, please help with consens gathering at the end of this thread...


With the aim of rapid adoption, I want to invite to an efficient discussion about the following question:

Please read over quickly about yapf, if you are not acquainted with it here: Using advanced clang-format algorithm, it aims at automatically solving almost EVERY style issue by piping the whole code through yapf.

  1. Would adoption be a benefit for OCA Development?
  2. What possible objections could be made?
  3. Is someone able/willing to implement it's adoption? How?

๐ŸŒŸ ๐ŸŒŸ ๐ŸŒŸ

In favor of gtd effectiveness, I rather explicitly ask for closing, if rapid implementation chances are low.

PROPOSAL: Improve Contributor Tooling

This evolves from and closes #145.

I claim, there is a benefit on incentive to converge contributor tooling, as odoo community, for the nature of the product, is characterized by many half-programmers. For the sake of efficient discussion, if you want to challenge this claim, please mark this specifically in your comment.

A generally adoptable tooling should be:

  • platform independent
  • easy to setup / automated
  • solve as many topics implicitly as possible

It comprises the following subsystems:

  • editor Subsystem / IDE
  • git subsystem
  • dev testing subsystem

Optimization candiates per Subsystem:

Editor / IDE:

  • snippets and templating
  • formatting
  • file layout

git subsystem:

  • feature workflow
  • correct origin/upstream setup
  • sorting/isolating of this messy (sorry for opnioning) multypurpose repositories, which I still not know how to do this...

dev testing subsystem:

  • platform independent
  • isolated (for the efimeral developer)
  • easy setup
  • autoreload on file change features
  • local or remote/proxy for individual and teams

Just to be said

Couldn't we rename this repo "maintainer-tools" ?

Each time I search something
in maintainer-quality-tools
or
in maintainers-tools

it bother me.

Am I the only one?

Including the description template in the contributing

What about we include the standard description template in the guideline. I am not sure where though
(keeping it as an example as below so people know how to use it)

.. image:: https://img.shields.io/badge/licence-AGPL--3-blue.svg
:alt: License: AGPL-3

Get back sales orders to draft

[Short description of you module
eg: Allows to get back to draft any cancelled sale order.]

Installation

Nothing special is needed to install this module.

Configuration

Nothing special is needed to configure this module.

Usage

When you cancel a sale order, you will see a new button call Back to draft,
that resets the sale order to draft state.

Known issues / Roadmap

None known.

Bug Tracker

[Where to post bug and issues
eg: Bugs are tracked on GitHub Issues <https://github.com/OCA/sale-workflow/issues>.
In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us smashing it by providing a detailed and welcomed feedback
here <https://github.com/OCA/sale-workflow/issues/new?body=module:%20sale_order_back2draft%0Aversion:%208.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>
.
]

Credits

Contributors

  • Contributor1
  • Contributor2

Maintainer

.. image:: https://odoo-community.org/logo.png
:alt: Odoo Community Association
:target: https://odoo-community.org

This module is maintained by the OCA.

OCA, or the Odoo Community Association, is a nonprofit organization whose
mission is to support the collaborative development of Odoo features and
promote its widespread use.

To contribute to this module, please visit http://odoo-community.org.

Migration With Diverged Parents

Our new migration instructions in the Wiki are awesome, but we seem to have an edge case when the parents diverged. If a module is created in another branch, the format-patch is not bringing those commits in.

Following is an example using stock-logistics-barcode:

$ git rev-parse --verify HEAD
4b8516e2bdfb2c9a95dc18f0e2da5e469811ecd3
$ git format-patch --stdout OCA/10.0..OCA/9.0 -- barcodes_generator_abstract | git am -3
$ git diff
$ git rev-parse --verify HEAD
4b8516e2bdfb2c9a95dc18f0e2da5e469811ecd3

Unfortunately my git-fu is not able to accomplish this feat without an intermediate merge commit, so I am creating this issue instead of fixing the wiki.

Edit: I didn't paste the checkout, but it was from OCA/10.0 & remotes updated

PROPOSAL: One Repo - One Module

For many, the actual layout of the OCA repositories is a headache. I'm sure there have been good reasons at the time of decision making to choose this layout, but I want to challenge them for the better.

The benefits of a "one repo - one module" structure:

  • simpler responsibility attribution (more fine grained maintainers)
  • much easier git flow handling
  • attribuible github issue tracking

However, it is NOT a question of weather one or the other!!!
Best of both worlds would be obtained by:
github.com/oca-dev with a "one-module - one repo" logic
github.com/oca with a project logic using git submodules

the git submodules approach adds the benefit that the PSC can do a more efficient work by using curated commits for each submodule individually in the github.com/oca repo.

CONTRIBUTING.md import rules conflict

There is a conflict between these two rules:

Rule 1:

The imports are ordered as

  1. Externals libs (One per line sorted and splitted in python stdlib)
  2. Imports of openerp
  3. Imports from Odoo modules (rarely, and only if necessary)
  4. Local imports in the relative form

Inside these 4 groups, the imported lines are alphabetically sorted.

Rule 2:

In python files where you use a import external_dependency_python_N you will need to add a try-except with a debug log.

 try:
  import external_dependency_python_N
except ImportError:
  _logger.debug('Can not `import external_dependency_python_N`.')

You should import the logger before other libraries. Otherwise you will not be able to do the logger.debug in the try-except.
My idea would be to modify the CONTRIBUTING.MD to include that the logging library needs to be the first library to be imported. What do you think?

Migration of modules from odoo 7.0 to odoo 8.0

Hello all,
(Advance apologies if this is not the right place for this issue)

As you know, there's a new 8.0 version and there to do a job migration python modules type grep-replace.
We are to work on this matter.
I would like to share our work with the OCA.

I need to know which is the right place to push this type of script.

Contributing wording

I do not or barely understand the following passages of the contributing.md due to syntactical inaccurracies or shortcomings.

except when compound of module name or object Odoo that is already in the plural

"Odoo" syntactically wrong at this position, what does the phrase want to express?

For models, views and data declarations, split files by the model involved, either created or inherited.

"split files by the model involved, either created or inherited": terrible english, make two phrases or rephrase. eg: "split files so that you have one file per model, no matter if this model is a new or inherited one"

Filename should only use only [a-z0-9_]

"only" duplicate

If a function call, dictionary, list or tuple is broken into two lines, break it at the opening symbol. This adds a four space indent to the next line instead of starting the next line at the opening symbol.
Example: python partner_id = fields.Many2one( "res.partner", "Partner", "Required", )

"at the opening symbol" (well what's an opening symbol) "at" refers to "before" or "after"? Imprecise.
"instead of starting" better: "instead of identing the next line until the nopening symbol". "identing" is more concise than "starting". Helps understanding.

When making a comma separated list, dict, tuple, ... with one element per line, append a comma to the last element. This makes it so the next element added only changes one line in the changeset instead of changing the last element to simply add a comma.

"This makes it so" - plain wrong english. The whole phrase is completly ununderstanable. Maybe just drop it? Or leave "this habit prevents annoying errors and therby improves your programming efficiency". I don't know, though, if this is what the phrase wanted to express..

Action method: an object action method is prefix with action_. Its decorator is @api.multi, but since it use only one record, add self.ensure_one() at the beginning of the method.

"prefix" > "prefixed"

@api.one method: For v8 is recommended use @api.multi and avoid use @api.one, for compatibility with v9 where is deprecated @api.one.

"is recommended use" "For v8, it is recommended to use" and ", for compatibility with v9, to avoide using @api.one FULLSTOP" "It is deprecated in v9."

A short explenation would be nice, because I was for some reason thinking it is the opposite (might be the same reason why this got relevance to put it there):

Do not prefix the xmlid by the current module's name (<record id="view_id"..., not <record id="current_module.view_id"...)

๐Ÿ‘Œ

Procedure to handle project roadmaps

It would be nice to have a generally agreed way to manage project Roadmaps.

We have these possibilities:

  1. A list in the repo README (example)
  2. A list in a repo Issue (example)
  3. Project Milestones (example)

Using the README roadmap additions are made through PRs, The discussion about the feature would go in the PR. Roadmap list management, including cleaning up done items, is done with repo commits (probably through PRs also).

Using a reference "Roadmap Issue" each proposed feature can be either an Issue or a PR, and each can also have their own discussions. Roadmap list additions still have to be maintained manually, but don't need a repo commit.

Using repo milestones, feature ideas are created, and Maintainers tag them with a milestone. Then GitHub automatically provides a dashboard with the roadmap status. No maintenance other than the individual Issues or PRs.

IMO using milestones seems to be the proper way. The project README could have a link to this list along with some text inviting to contribute.

It may be interesting to have specific milestones for feature roadmap and maybe wishlist, such as 8.0-roadmap and 8.0-wishlist.

Thoughts?

Proposal: How to quickly get started with template

Here's a quick way to get started on contributing a new module

# Clone the appropriate OCA repo from your own fork
git clone [email protected]:${YOUR_OWN_FORK}/${OCA_MODULE_REPO}.git
cd ${OCA_MODULE_REPO}
# Add maintainer-tools to have access to the template module and block pushing
git remote add -f maintainer-tools [email protected]:OCA/maintainer-tools.git
git remote set-url --push maintainer-tools no-pushing
# Checkout new feature branch with a desired name
git checkout -b  ${NEW_BRANCH_NAME}
# Get the template module
git checkout maintainer-tools/master -- template/module
# Move and rename the template to the desired name
git mv template/module ${NEW_MODULE_NAME}
# Start working on the module
# Make pull request

I might even recommend using an orphan branch if the module doesn't have any dependencies with the other modules in the repo.

# Clone the appropriate OCA repo from your own fork
git clone [email protected]:${YOUR_OWN_FORK}/${OCA_MODULE_REPO}.git
cd ${OCA_MODULE_REPO}
# Add maintainer-tools to have access to the template module and block pushing
git remote add -f maintainer-tools [email protected]:OCA/maintainer-tools.git
git remote set-url --push maintainer-tools no-pushing
# Checkout new orphan feature branch with a desired name
git checkout --orphan ${NEW_BRANCH_NAME}
git reset --hard
# Get the template module
git checkout maintainer-tools/master -- template/module
# Move and rename the template to the desired name
git mv template/module ${NEW_MODULE_NAME}
# Start working on the module
# Make pull request

Modules that add one field

I would like to open the debate on whether or not to accept modules that add only one field. In my opinion, it should not, because we end up with many dependencies between modules and no global coherence. I would like to hear what you people think on this matter.

Cannot set the labels to all repos

Steps to reproduce

  1. install the maintainer tools via
    sudo python setup.py install
  2. login in github:
    eric@eric--XPS-15Z:~/CVS/oca/maintainer-tools$ oca-github-login elicoidal
    Password for elicoidal:
    Token stored in configuration file
  3. Launch the script
    eric@eric--XPS-15Z:~/CVS/oca/maintainer-tools$ oca-set-repo-labels

Current behavior

the set up seems incomplete and the reasons are not clear, neither how to continue:
Repo account-analytic - Found 3 extra labels
8.0
in progress
7.0
Repo account-budgeting - Found 2 extra labels
8.0
7.0
Repo account-closing - Found 2 extra labels
8.0
7.0
Repo account-consolidation - Found 2 extra labels
8.0
7.0
Repo account-financial-reporting - Found 3 extra labels
8.0
7.0
Pending CLA
Repo account-financial-tools - Found 2 extra labels
8.0
7.0
Repo account-fiscal-rule - Found 2 extra labels
8.0
7.0
Repo account-invoice-reporting - Found 2 extra labels
8.0
7.0
Repo account-invoicing - Found 3 extra labels
8.0
needs tests
7.0
Repo account-payment - Found 3 extra labels
8.0
needs tests
7.0
Repo bank-payment - Found 4 extra labels
CLA Pending
8.0
7.0
approved
Repo bank-statement-import - Found 2 extra labels
8.0
7.0
Repo bank-statement-reconcile - Found 2 extra labels
8.0
7.0
Repo business-requirement - Create 3 missing labels
Traceback (most recent call last):
File "/usr/local/bin/oca-set-repo-labels", line 10, in
sys.exit(main())
File "/usr/local/lib/python2.7/dist-packages/tools/set_repo_labels.py", line 57, in main
success = repo.create_label(label_name, all_labels[label_name])
File "/home/eric/.local/lib/python2.7/site-packages/github3/decorators.py", line 38, in auth_wrapper
return func(self, _args, *_kwargs)
File "/home/eric/.local/lib/python2.7/site-packages/github3/repos/repo.py", line 683, in create_label
json = self._json(self._post(url, data=data), 201)
File "/home/eric/.local/lib/python2.7/site-packages/github3/models.py", line 100, in _json
if self._boolean(response, status_code, 404) and response.content:
File "/home/eric/.local/lib/python2.7/site-packages/github3/models.py", line 121, in _boolean
raise GitHubError(response)
github3.models.GitHubError: 422 Validation Failed

Repeating the script ends to the same output.

Expected behavior

all repos are labeled

Add docker test for transifex

Currently we have a new Dockerfile for transifex bot.

I saw that travis now support docker

We can add a travis job to build the transifex bot image, self-test, auto docker push to oca images

Before of work, your feedback is welcome.

The bad news is the time of each travis job: will increase 5 minutes.
The good news is that we can have the image updated, and test it if is working fine.

[REF] contributing: What with .pot file in i18n/ folder?

Now with the use of transifex... is unnecesary to add .pot file in i18n of modules.
The question is: What should be our guideline?
A) File .pot required in each module of oca.
B) Don't add .pot file never.
C) You can choose if add .pot file or not.

What do you think?

License placement policy in modules

There is no mention in the contributing.md file about how to insert the license in the files.
AFAIK the latest policy is to have a LICENSE.txt and long descriptor in the openerp.py and make reference of it in the other py files.

I think we should add it as a guideline

Clarification of Many2x field naming

In the guidelines, we can read:

Since new API works with records or recordsets instead of id lists, don't suffix variable names with _id or _ids if they do not contain an ids or lists of ids.
...
res_partner = self.env['res.partner']
partners = res_partner.browse(ids)
partner_id = partners[0].id

And:

One2Many and Many2Many fields should always have _ids as suffix (example: sale_order_line_ids)
Many2One fields should have _id as suffix (example: partner_id, user_id, ...)

So what should we follow ? I prefer the first proposal because it make more sense to me.

Images in module description not properly displayed on app.store and in the list of local modules in an odoo instance.

The module description is the key element to promote our modules. For modules under OCA, the rule is to put this description in a README.rst file following some specific guidelines. (https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#modules)
This file is used by github, odoo and odod.app.store to provide a nicely formatted description of our modules.
When trying to get a nice description of the mis_builder module under all these places I've observed the following problems:

  • If you references some images in your description (images stored in static/src/description), even if your file looks fine on github, images are missing in odoo and app.store.
  • The licence bagde is not displayed in the app.store

File under github:
image

Description in Odoo:
image

Description app.store:
image

The problem for the images is that the rules to be correctly rendered are not the same depending of the target.

  • For github the path to the image must be /static/..../my_img.png
  • For Odoo /my_module/static/..../my_img.png
  • For app.store my_img.png

For the licence badge, when the file is converted to html5, the image is put directly under the body element and not into a section element. My hypothesis is that the app.store keeps only from the conversion result the 'section' elements (This hypothesis will be verified once OCA/sale-workflow#54 will be merged).

For mis builder, I've solved the problem by manually generating an html description from the REAMDE.rst file. (OCA/account-financial-reporting@6db1e21)
The description is now correctly formatted everywhere.

This kind of process can be easily automated and launched in the after_success script by travis but is it really the good solution?

FirstName LastName in Reverse Order

Milestone (Odoo version)

  • Version 10 Enterprise

Module(s)

  • Firstname Lastname

Steps to reproduce

  1. After Install

Current behavior

We have all of our contacts in as FirstName LastName in the name field. After the Firstname Lastname module is installed, upon edit of contact the module is pulling back the Lastname Firstname in that order. Is there a way to have the module pull back FirstName LastName?
firstnamelastname_ocamodule

Expected behavior

Module pull back FirstName LastName in correct order.

[WIKI][FIX] Do not export i18n folder of module when migrating to newer version

Milestone (Odoo version)

  • 9.0/10.0

Module(s)

Any OCA module

Steps to reproduce

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0#technical-method-to-migrate-a-module-from-80-to-90-branch.

Current behavior

Updates i18n commits to 9.0 and conflicts arises.
Normally, transifex automatically creates file for each branch, so we could skip the export of i18n folder

git format-patch --stdout origin/9.0..origin/8.0 -- <module path> **':!<module_path>/i18n'** | git am -3
e.g.
git format-patch --stdout origin/9.0..origin/8.0 -- magentoerpconnect ':!magentoerpconnect/i18n' | git am -3

Expected behavior

no conflict when performing the migration.

Note: created issue after discussing in OCA IRC chat
https://botbot.me/freenode/oca/2016-10-18/?msg=75006135&page=1

Changing from openerp to odoo

Hi,
I have noticed that now we have the possibility to use the keyword odoo instead of openerp (for example in import or xml files).
Shall we start enforcing it in our module?
Does somebody know from which version it is allowed and which mandatory?

crash on python setup.py develop

Is there a minimum requirement of setuptools / pip for running python setup.py develop?

afayolle:/work/oca/OCA-tools/maintainers-tools$ . env/bin/activate
(env)afayolle:
/work/oca/OCA-tools/maintainers-tools$ python setup.py develop
running develop
running egg_info
writing requirements to oca_maintainers_tools.egg-info/requires.txt
writing oca_maintainers_tools.egg-info/PKG-INFO
writing top-level names to oca_maintainers_tools.egg-info/top_level.txt
writing dependency_links to oca_maintainers_tools.egg-info/dependency_links.txt
writing entry points to oca_maintainers_tools.egg-info/entry_points.txt
[pbr] Reusing existing SOURCES.txt
running build_ext
Creating /home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/lib/python2.7/site-packages/oca-maintainers-tools.egg-link (link to .)
oca-maintainers-tools 18f0170 is already the active version in easy-install.pth
Installing oca-copy-maintainers script to /home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/bin
Installing oca-github-login script to /home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/bin
Installing oca-copy-branches script to /home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/bin

Installed /home/afayolle/work/community_addons/OCA-tools/maintainers-tools
Processing dependencies for oca-maintainers-tools==18f0170
Searching for uritemplate.py==0.3.0
Reading https://pypi.python.org/simple/uritemplate.py/
Best match: uritemplate.py 0.3.0
Downloading https://pypi.python.org/packages/source/u/uritemplate.py/uritemplate.py-0.3.0.tar.gz#md5=4dd14904ba502c6ff8d6276e004404de
Processing uritemplate.py-0.3.0.tar.gz
Writing /tmp/easy_install-Imr6qL/uritemplate.py-0.3.0/setup.cfg
Running uritemplate.py-0.3.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Imr6qL/uritemplate.py-0.3.0/egg-dist-tmp-yVRHUY
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'include_package_data'
warnings.warn(msg)
Traceback (most recent call last):
File "setup.py", line 5, in
package_data={'': ['*.yaml']})
File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/develop.py", line 27, in run
self.install_for_development()
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/develop.py", line 129, in install_for_development
self.process_distribution(None, self.dist, not self.no_deps)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 706, in process_distribution
[requirement], self.local_index, self.easy_install
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/pkg_resources.py", line 618, in resolve
dist = best[req.key] = env.best_match(req, self, installer)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/pkg_resources.py", line 862, in best_match
return self.obtain(req, installer) # try and download/install
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/pkg_resources.py", line 874, in obtain
return installer(requirement)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 623, in easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 653, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 849, in install_eggs
return self.build_and_install(setup_script, setup_base)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1130, in build_and_install
self.run_setup(setup_script, setup_base, args)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1115, in run_setup
run_setup(setup_script, args)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 69, in run_setup
lambda: execfile(
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 120, in run
return func()
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 71, in
{'file':setup_script, 'name':'main'}
File "setup.py", line 42, in

File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 970, in run_command
cmd_obj = self.get_command_obj(command)
File "/usr/lib/python2.7/distutils/dist.py", line 846, in get_command_obj
cmd_obj = self.command_obj[command] = klass(self)
File "/home/afayolle/work/community_addons/OCA-tools/maintainers-tools/env/local/lib/python2.7/site-packages/setuptools/init.py", line 60, in init
_Command.init(self,dist)
File "/usr/lib/python2.7/distutils/cmd.py", line 59, in init
raise TypeError, "dist must be a Distribution instance"
TypeError: dist must be a Distribution instance

Numbering version in template for readme file

I suggest to indicate the branch in feedback url as following, having a version in template says to me (IMHO) that is the module version as pointed out in CONTRIBUTING.md in L25 with semantical way. But in fact is the branch that the module actually is.

Current template:

{project_repo}/issues/new?body=module:%20
{module_name}%0Aversion:%20
{version}%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Proposal template:

{project_repo}/issues/new?body=module:%20
{module_name}%0Aversion:%20
{branch}%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Permissions in github

I was able to edit this project wiki just a few moments ago. It was for a fix (a typo in PEP8 url link) and with good spirit, of course, but... Is it supposed that way? As I am not in the members list, can anyone edit it?

Just to avoid any future problem.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.