openerp-community team mailing list archive

[Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>]

Hi, Daniel,

Indeed, I didn't use the correct words. I meant be a member of
openerp-community-reviewer team in Launchpad (or in the similar
administrative group in other VCS), and this is linked with the next
statement: highlight these members as a reward. Does this make sense to you?

Regards.


2013/11/7 Daniel Reis <dgreis@xxxxxxx>

>  Nice summary Pedro.
>
> But there is a statement there that raised my attention: "Set a path to
> contributors to become reviewers"
> I may be missing something, but as far as I know, there are no vested
> reviewers:
> anyone can be a reviewer in any MP they feel confident enough to give an
> opinion about.
> Only a few are able to actually do the merge, but that's just the
> "administrative" part of the MP.
>
>
> Regards
> Daniel
>
> Quoting Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>:
>
>  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
>>
>
>
>
>