oca / maintainer-tools Goto Github PK
View Code? Open in Web Editor NEWOdoo Maintainers Tools & conventions for OCA members which evaluate and maintain repositories.
License: GNU Affero General Public License v3.0
Odoo Maintainers Tools & conventions for OCA members which evaluate and maintain repositories.
License: GNU Affero General Public License v3.0
Use : https://github.com/facebook/mention-bot
Note this module already interact with github and odoo https://github.com/legalsylvain/oca-custom
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:
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.
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)
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.
I don't saw test folder in guidelines of contributing.
TODO: Make PR with this guideline
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.
all repos are labeled
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
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.
If the proposal is approved, I can set a roadmap here to start the job.
Thanks in advance.
The labels for PRs are missing some options, such as Needs Fixing and Work In Progress.
Could it an issue on the script automating the label creation?
Example: OCA/l10n-portugal#5
(and later automate it in mqt)
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.
I just created the 8.0 branch for OCA/department and OCA/project-service repos.
Could an OCA Owner edit their Settings to make them the "Default branch"?
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?
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?
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/
Write a script to be triggered during a merge:
version
has changed in the manifest of all the modules of the branch (better detection could be implemented later)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
The guidelines state where we should store the models, views etc, but does not indicate where reports must go.
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
[Short description of you module
eg: Allows to get back to draft any cancelled sale order.]
Nothing special is needed to install this module.
Nothing special is needed to configure this module.
When you cancel a sale order, you will see a new button call Back to draft,
that resets the sale order to draft state.
None known.
[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**>
.
]
.. 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.
HI @OCA/tools-maintainers,
I would like to ask why has been removed in README the link to open issues? It was very useful.
Thanks
Related to OCA/website#221
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.
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.
What do you think ?
Any OCA module
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
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
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**>`_.
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?
There is a problem with OCA logo referenced (http://odoo-community.org/logo.png) in the README files, that makes it to not show up.
@gurneyalex or any board member, can you check it?
There is good guidelines here:
We should add someone.
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?
Is there a minimum requirement of setuptools / pip for running python setup.py develop?
afayolle:/work/oca/OCA-tools/maintainers-tools$ . env/bin/activate/work/oca/OCA-tools/maintainers-tools$ python setup.py develop
(env)afayolle:
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
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
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
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.
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.
- 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 tittleThen, create a new issue, with the following information:
Then, create a new issue, you have two ways:
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.
- Push your code and create a pull request
Please set tittle of PR like:
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
There is a conflict between these two rules:
Rule 1:
The imports are ordered as
- Externals libs (One per line sorted and splitted in python stdlib)
- Imports of
openerp
- Imports from Odoo modules (rarely, and only if necessary)
- 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 atry-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?
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?
Module pull back FirstName LastName in correct order.
Read #29 to know more about it
While making the merge, please respect the author using the --author option when committing. The author is found using the bzr log command.
bzr log
should be replaced by git log
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"...)
👌
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**>`_.
I see in this section https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#pep8-options:
should adhere to PEP8 and PyFlakes standards standards
I assume this part of sentence is wrong but I don't know what it is the right one. Perhaps @bwrsandman could you help me in order to make a proper PR.
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:
The problem for the images is that the rules to be correctly rendered are not the same depending of the target.
/static/..../my_img.png
/my_module/static/..../my_img.png
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?
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.
🌟 🌟 🌟
In favor of gtd effectiveness, I rather explicitly ask for closing, if rapid implementation chances are low.
The LINT_CHECK tests of Travis are failing for my PRs because the author contains u"Numérigraphe"
, which is supported by Odoo but raises an exception during the tests.
Example failure log: https://travis-ci.org/OCA/stock-logistics-warehouse/jobs/80427466#L205
Example PRs affected: OCA/stock-logistics-warehouse#80, OCA/stock-logistics-warehouse#81
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.
oca-github-login
eric@eric--XPS-15Z:/CVS/oca$ oca-github-login elicoidal/CVS/oca$ ls
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:
maintainer-tools oca.cfg
eric@eric--XPS-15Z:/CVS/oca$ oca-clone-everything/CVS/oca$ rm oca.cfg
No token has been generated for this script. Please run 'oca-github-login'.
eric@eric--XPS-15Z:
eric@eric--XPS-15Z:/CVS/oca$ ls/CVS/oca$ oca-github-login elicoidal
maintainer-tools
eric@eric--XPS-15Z:
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/CVS/oca$ oca-clone-everything
maintainer-tools oca.cfg
eric@eric--XPS-15Z:
No token has been generated for this script. Please run 'oca-github-login'.
cannot clone oca repository due to the login behavior
It would be nice to have a generally agreed way to manage project Roadmaps.
We have these possibilities:
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?
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.