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 <[email protected]> > 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 <[email protected]>: > > 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 <[email protected]> > >> On Wed, Nov 6, 2013 at 10:48 AM, Joël Grand-Guillaume < >> [email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community-reviewer >> More help : https://help.launchpad.net/ListHelp >> > > > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
