Make this a package installable opensourcing in the right way.

[nhomar]

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.

[pedrobaeza]

This job was already started here: https://github.com/OCA/maintainer-tools/pull/78

[nhomar]

Ok... I will comment there.

but BTW if you read the link, it is too much more that simpli make it pip installable.

but cool I will check that job (which is only 1 of 12 or 14 steps on the document linked).

regards.

[pedrobaeza]

The link talk about open-source projects, which is equivalent to Odoo/OCA projects, not the maintainer tools, and I see that there pretty almost all the jobs done (translations, Travis...)

[nhomar]

@pedrobaeza

The link talk about "How to oponsource them correctly" please read complete what we share before comment because you block other points of view some times.

If you read carefully (the author is one of the mos famous programmers in python around the globe) you can read his book here It is a perfect step by step about how opensource a python package (this specific repository should be a perfect done python package).

Following the index:

1. Project layout (directory structure)
2. setuptools and the setup.py file
3. git for version control
4. bug tracking
5. feature requests
6. planned features
7. release/version management
8. git-flow for git workflow
9. py.test for unit testing
10. tox for testing standardization
11. Sphinx for auto-generated HTML documentation
12. TravisCI for continuous testing integration
13. ReadTheDocs for continuous documentation integration
14. Cookiecutter to automate these steps when starting your next project

Of this 15 14 point (to help everybody how do I see we are).

Point 1.- The project layout can be improved, following a better directory structure (using what is recommended in point 16). TODO Point 2.- setuptools and the setup.py file is done but the most basic one and is the jor which is being achieved in the issue #78. <- WiP Point 3.- git <- Done. Point 4.- Bug Tracking DONE, Point 5.- Feature Request DONE, Point 6.- Planned Features DONE, Point 7.- Release/Version "In discusion for modules but not for this specific package" let's say TODO. Point 8.- git-flow (To discuss, but I am fine with the actual flow then let's say) N/A. Point 9.- Tests Standarization: TODO. Point 10.- Tests: TODO. Point 11.- Sphinx: TODO. Point 12.- travis (configured but basically is not doing anything just running the setup.py, if 9 is done only one line need to be added) let's say DONE. Point 13.- Readthedocs TODO. Point 14.- Formats and folders standarized (coockiecutter) TODO. Point 15(in the body not in the index) DOc tests TODO.

OF 15 Points we have:

7 TODO. 1 WIP. 5 DONE 1 N/A.

Do you think can we open the discussion about such 7 point ?

Thanks for comments.

[pedrobaeza]

I don't block any point of view, but your TODO list is not totally correct, but I'm not going to enter into details right now, because your time and mine are precious, so let's deal with each of the point in their right moment and of course I want to do all "the right way" :wink:

[nhomar]

And to be clear, I am talking about only this repository, no all OCA. (just to clarify if it was not clear enought.)

[dreispt]

@nhomar I believe that these points also apply to the MQT repo. I also feel that the contribution guidelines and similar generic community docs should be in an OCA repo of their own, but that's another story...

[nhomar]

@nhomar I believe that these points also apply to the MQT repo.

Absolutly, but let 's make the change here first and then move all decisions to mqt. What do you think?

I also feel that the contribution guidelines and similar generic community docs should be in an OCA repo of their own, but that's another story...

Yes I can be agreed on that, and add to the repository itself a link to the website.

[nhomar]

I also feel that the contribution guidelines and similar generic community docs should be in an OCA repo of their own, but that's another story...

About this my only concern is that the repository will represent all the tools that we the mantainers can be using day after day.

Even, I am talking about this repository because it is the cleanest one to start, but even IMHO we can merge this set of mt and mqt one time mt is perfectly cleaned and following standards, the issue there is that mqt is too sensitive du to it affects 100% of repositories.

Just to be sure, you are agreed with this improvements then?

[dreispt]

@nhomar Sounds good, but the most important thing is that we agree the direction, and steps forward are taken.

[nhomar]

@dreispt absolutly.

I love the link I showed up, it is very well explained and honestly you only follow the steps and everything works like magic.

we have some package managed on that way but yes, I am absolutly agreed with you, one time the direction is stablished we can move forward.

With another +1 i can make a first PoC with PR included. just to discuss over ther with code and not ideas..... Do you think is it feasible?

[dreispt]

To be honest, I don't participate a lot here, I see this mostly a collection of admin scripts use by a few other people. But MQT is another story: is is widely used, both in OCA and both in people's personal Odoo repos. So I rather comment from the later perspective.

From your step list, most look OK. I only need to comment these:

Point 10.- tox tests: TODO.

For MQT, we're stuck into 2.7, so no point in this.

Point 13.- Readthedocs TODO.

Personally, I don't see the problem with reading the Docs on GitHub.

Point 14.- Formats and folders standarized (coockiecutter) TODO.

Not a real step to open soruce a pparticular project/repo, so I say that it's N/A.

Point 15(in the body not in the index) DOc tests TODO.

I don't understand this one.

[guewen]

It is installable as a pip package since the beginning. Regarding the TODO list, I don't think all of them are necessary as stated by @dreispt.

[charbeljc]

@guewen, you are right, thanks for the precision. The point of my work in #78 is to make all parts of oca.tools importable so we can reuse it to bulid other tools upon them. My main concern was the inability to get the package list without network connectivity to github, which is adressed now.