openerp-community team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Forgot this link about the review process for you Michel :
https://doc.openerp.com/contribute/05_developing_modules/#community-review


On Thu, Nov 7, 2013 at 10:06 AM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

> Dear Community,
>
>
> First, I want to thank you Michel for trying to respect the community
> process and tools. I know it's a bit of work, but it's mandatory to
> maintain quality. I hope you had all your answer (making a fork and go
> through Merge Proposal when requesting an update, so the review can occur,
> even for your first one).
>
> Secondly, I'm completely in-line with Perdo's opinion about what goal do
> we pursue. It took us (and me) lots of time to setup all those LP
> repository, team, branches and all that stuff to make the OpenERP community
> a reality.
>
> Now we finally reach something.. Thanks to all of you ! It starts to work
> and attract the interest of people and I'm really happy on that.
>
> But, even if I know LP and Bazaar sucks on some points, it works. It's
> organized, reviews are made and the process and tools are clear enough to
> enough people do the job.
>
> For that reason, I'm strongly in favor of keeping our work there for now.
> We barely have enough resources to make all the needed reviews and I think
> moving to GitHub will not help on that but rather introduce quite lots of
> overhead till we reach what we have now.
>
> My suggestion is :
>
>  * Keep LP and Bazaar for now and at least, let's say a year or two
>  * Keep improving the reviews process, docs and so on so new comers can
> join the effort
>  * Starts to run the OCA (we're working on it this month)
>  * When we starts having a comfortable situation, let's move to GitHub or
> anywhere else you want, I actually don't really care about the tools. I
> care about building this community and make it stronger.
>
> I know Raphaël, you angry with Bazaar and Github is better suited. I know
> you find the packing system a pain in the ass and I agree. But let's make
> with what we have till we're strong enough to change that !
>
> Regards,
>
>
> Joël
>
>
>
>
>
>
>
>
>
>
> On Wed, Nov 6, 2013 at 5:32 PM, Pedro Manuel Baeza Romero <
> pedro.baeza@xxxxxxxxx> wrote:
>
>> Hi, community,
>>
>> Sorry in advance for the long message.
>>
>> I think we have to talk about two different topics that are under the OCA
>> umbrella: OCB branches and community repositories.
>>
>> For *OCB branches*, there are not too much discussion: it's mandatory
>> that we have them on Launchpad, because there are too many dependencies on
>> LP that cannot be avoided (see this Olivier Dony answer<https://lists.launchpad.net/openerp-community/msg03629.html>about this question on other thread) and we must go here together with
>> OpenERP S. A.
>>
>> About *community repositories*, the question that Raphael has exposed is
>> critical: the future and maintanability of them. Having lived a part of the
>> evolution of them, this is what I think:
>>
>>    - In some way, we are trying to compensate the lack of a global
>>    quality OpenERP repository. OpenERP Apps doesn't count, because the
>>    categorization in it is not very accurate (it depends on the module
>>    manifest) and there is a lot of "dummy" modules that makes a few (usability
>>    module, for example).
>>    - The only way we have for now is to group relevant modules in a
>>    repository to make it in somehow available to the groups of interest.
>>    - We have used Launchpad to continue with the same tools as the
>>    mother project.
>>    - These tools have conditioned the organization / reviewing process.
>>    - Although we are admitting a lot of new modules, it follows some
>>    criteria (for now based on the sense of the reviewers) to avoid only
>>    usability modules (we have talked about this on other thread also).
>>    - Reviewers can use their expertise to teach newcomers on good
>>    practises, and these newcomers will be soon the next teachers (this is for
>>    example my case). This musn't been interpreted as a dictatorial regime, but
>>    some work rules to assure quality. If these practises are not correct, we
>>    can change or refine them.
>>    - We don't have the obligation to maintain across the versions all
>>    the modules that are included in some momment on the community
>>    repositories, but to assure that when something arrives to them (a new
>>    module or an adaptation to a new version of an old one), it has enough
>>    quality to enter.
>>    - These reviewings can be exhausting, but we are attracting each day
>>    more contributors that helps with this process.
>>    - Nobody have the obligation to publish their modules on community
>>    repositories. They can use their own repositories, even hosting on others
>>    CVS.
>>    - My hope is to set these repositories as the reference where someone
>>    goes when he wants to contribute.
>>
>> So, said that, to keep this initiative healthy, this is IMHO what we have
>> to do:
>>
>>    - Set clear rules for the reviewing process. This is already done and
>>    will be merged on official documentation.
>>    - Set a path to contributors to become reviewers.
>>    - Reward contributors with some visibility on OCA mediums (web and so
>>    on), to encourage new contributions.
>>    - Set rules for admission of modules. This is not easy, but it can be
>>    done with a few exceptions.
>>
>> Now, about *Launchpad and GitHub*, I feel the same as Raphael in the
>> questions he told (performance, acknowledgment, subprojects, etc), and
>> maybe we can switch community repositories to GitHub to avoid questions
>> like the one that has started this debate, but this must be assured:
>>
>>    - We have a way to integrate translations for easy contributions. I'm
>>    already working on having Launchpad translations on community repositories
>>    and I see this as mandatory.
>>    - We must assure atribution and permissions.
>>    - We cannot lose contribution history.
>>    - Reconstruct documentation with the new contribution path.
>>    - We must have anyway synched Launchpad repository/repositories to
>>    enable modules on apps.openerp.com.
>>
>> As you see, this a lot of work to do and questions to solved, but
>> Raphael, if you're willing to work on this, I can help you and propose to
>> the community a concrete proposal to make the switch.
>>
>> Regards.
>>
>>
>>
>>
>> 2013/11/6 Raphael Valyi <rvalyi@xxxxxxxxx>
>>
>>>  On Wed, Nov 6, 2013 at 10:48 AM, Joël Grand-Guillaume <
>>> joel.grandguillaume@xxxxxxxxxxxxxx> wrote:
>>>
>>>> Dear all,
>>>>
>>>>
>>>> First thanks you Michel to take the time for that ! Now, I'm a bit
>>>> concerned because we didn't really face this before.
>>>>
>>>> The
>>>> https://code.launchpad.net/~openerp-community/openobject-addons/7.0-booking-chart
>>>> is more a module that should be included in one of our project, and I
>>>> don't which one, any idea ?
>>>>
>>>> Then the branch of the
>>>> https://code.launchpad.net/~openerp-community/web-addons/7.0-web-unleashed
>>>> is on the right place, but it contains a branch replicated from
>>>> github... That prevent any merge to be done in the "official" community
>>>> branch here : lp:web-addons<https://code.launchpad.net/%7Ewebaddons-core-editors/web-addons/7.0>
>>>>
>>>> That's a bit sad.. Any suggestion here ? How to handle GitHub branches ?
>>>>
>>>
>>>
>>> Hello Joël and others,
>>>
>>> if a branch is Github driven and replicated on Launchpad, merging a
>>> Launchpad MP isn't that hard: in your git branch just import the branch
>>> using the native git ber remote helper
>>> http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
>>> merge inside your git using usual git merge command, push to Github
>>> (then auto-replicated to Launchpad) and voila! Still Github submitted
>>> merges are easier to deal with.
>>>
>>> Of course, now if a module should integrate a branch driven on
>>> Launchpad, then probably it's better to let it be developed on Launchpad.
>>>
>>> Now a bit more about this: "should a module integrate some existing
>>> Launchpad branch?"
>>> In any case, people should remember that we currently group modules
>>> together just because OpenERP don't have any decent package manager that
>>> deal with version constraints and multiple repo location. And as you read
>>> this, please OpenERP SA don't try to reinvent a package manager (apps?),
>>> that's something hard, OpenERP should standardize instead of wasting
>>> resource on these solved problems.
>>> And again, it's not like if I am only "talking":
>>>
>>> https://code.launchpad.net/~akretion-team/openobject-server/trunk-extra-depdencies-info/+merge/114172
>>>
>>> But in any case, grouping modules in the same branch is rather a
>>> temporary artifact and a bad design than anything else.
>>>
>>> Instead, once it becomes decent to install pinned versions via package
>>> manager and test with standard Continuous Integration tooling,
>>> **we should tend to 1 module = 1 branch**
>>> That's how all the modular dynamic ecosystems work. Of course, we could
>>> still have a few exceptions. If you take the Ruby ecosystem (extremely
>>> modular and works well), you see that usually 1 module = 1 Github repo. But
>>> as for the Rails repo, it's 5 modules altogether in the same repo (but only
>>> 5, while a typical Rails project will depend on 50+ modules). It's an
>>> exception and it still works. I know it less, but I think it's the same for
>>> Pypi, right?
>>>
>>> If we keep grouping modules blindly, that will not scale in term of
>>> complexity: soon there will be tons of merge for modules that are unknown
>>> to most of a project team, that will be slow/frustrating or badly reviewed.
>>> We will have branches of these god branches incompatible between them and
>>> branch cross dependencies nightmares.
>>>
>>> With that in mind, I think it would be an error to think that only a few
>>> people should determine a single forge for all the OpenERP eco-system,
>>> specially if that forge sucks (I didn't tell Launchpad sucks, you are
>>> interpreting here ;-)
>>>
>>> I think it really make sense to use a single forge for the core, but as
>>> for the whole eco-system, we would try to impose bad tooling to good
>>> willing people and that will not work.
>>>
>>>  It's cool also to have OpenERP SA and OCA doing some centralization
>>> work trying to develop and review core modules, but in any case, it will
>>> never scale to imagine that just a dozen of people will review the entire
>>> eco-system at every-commit. I think that instead there will be lot's of
>>> projects, lot's of team, ideally good practices in many places and possibly
>>> some centralization but only for the core things. If if try to centralize
>>> and decide for everything, then we will have a sub-optimal core (because
>>> work is diluted with non core things) and a frustrated community that see
>>> its freedom to innovate restricted.
>>>
>>> Now
>>> <my personal opinion about Launchpad and bzr>
>>> it does the job, but hell it doesn't do it well. Here it's very common
>>> that bzr branch --stack addons takes over 20 minutes (1h30 without stacked)
>>> vs 8 minutes for the same Github shallow clone. Want to compare
>>> purchase_requisition in 7.0 against trunk? in git it's a breeze, in bzr
>>> slow as hell. If you have a bzr branch that you want to do pull after some
>>> 2 months (branch for some customer?), bzr pull can easily take more than 1
>>> hour... (and we tried everything, local bzr mirrors etc...)
>>> Also I don't see much activity on bzr repo to fix this. It isn't really
>>> cloud ready and it's like both bzr and Launchpad are loosing the battle
>>> here.
>>> So I'm perfectly okay to contrib on Launchpad. But when I do so, I
>>> always think it's temporary and that one day anyway Launchpad will probably
>>> announce that it's closing and we will need to put all these little team
>>> and karma in the trash and move all that to some git (or hg) forge.
>>> Other things I don't like about LP: it really badly sells a project:
>>> navigation is awkward to newcomers, documentation isn't integrated, project
>>> dynamism doesn't drive to adhesion. Also, we aren't as rich as SAP or
>>> Microsoft, right? So what we need? We need contributors hell! but again
>>> Launchpad badly reward contributors vs Github that does it so well that a
>>> Github profile starts to be what a recruiter will look at to evaluate a job
>>> candidate (compare this to hackable karma...)
>>> Anyway this is just
>>> </my personal opinion about Launchpad and bzr>
>>> (now I said it)
>>>
>>>
>>> So as a conclusion:
>>> I say no to a dogma that we should group modules inside the same
>>> branches. That's only a temporary work-around while some believe or make
>>> believe things like apps is more important than pip modules.
>>>
>>> In the meanwhile, it's not because that there are several branches that
>>> there cannot be projects hub and their teams: a common team could take care
>>> of several projects, on several branches and possibly forges.
>>>
>>>
>>> Finally, I think we should investigate the great work of Vo Minh Thu
>>> regarding OpenERP module packaging:
>>> http://assertive.io
>>>
>>> My issue still is: if we have a new addons version at every commit, then
>>> for any delta update pip update of the addons it will probably re-download
>>> 400+ Mo of all the fresh addons vs a few ko if you were doing a bzr or git
>>> pull. Again, not exactly cloud ready...
>>> Given the very relative stability of OpenERP, I only have seen success
>>> of people doing these delta updates on their projects to fix bugs as they
>>> encounter and fix them. Today I don't see this working with assertive yet.
>>> I may just be dreaming, but instead I was thinking about something like:
>>> for all modules we have git-subtree (no working bzr equivalent!) cron that
>>> put every module in a single branch: the module version get incremented
>>> only if this particular module receives a commit. Possibly, a translation
>>> commit is the z of the x.y.z semver. Then doing pip update would
>>> re-download the module only if it received commits, and possibly only if
>>> these commits aren't just translation.
>>>
>>>
>>> My two 2 cts. Thanks to all for these input about that essential topic.
>>>
>>>
>>> --
>>> Raphaël Valyi
>>> Founder and consultant
>>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>>> +55 21 2516 2954
>>> www.akretion.com
>>>
>>>
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~openerp-community-reviewer
>>> Post to     : openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-community-reviewer
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> --
>
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Joël Grand-Guillaume*
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> www.camptocamp.com
>
>
>


-- 


*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Joël Grand-Guillaume*
Division Manager
Business Solutions

+41 21 619 10 28
www.camptocamp.com