May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MetaRepoForPharo40

by Nicolas Cellier

2014-05-28 14:43 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2014-05-28 10:26 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > >> Am 28.05.2014 um 10:08 schrieb kilon alios <kilon.alios(a)gmail.com>: >> >> Well I am a big fan of github and git myself. Though I also love >> smalltalkhub , so far I had no serious issues with it apart from the site >> going down at times and not being able to browser new projects. >> >> The thing with public access is that you don't worry about it unless a >> problem occurs. Which saves time and is less demanding on the maintenance >> side. I will have to agree that github repo with pull requests would be >> ideal. None the less , things look that are moving towards a better >> direction :) >> >> You can have public access in each individual project. Iâm just saying >> that the configuration of a project is only copied to _the_ pharo software >> catalog if it isnât broken. So while everyone has public access to a >> project and there is an automatic build on a CI the configuration will be >> arrive in the meta repo sooner or later. No one has to do anything. >> If public access would the best way to go pull requests wouldnât be so >> prominent. It is a solution to let people easily participate without having >> access to a repository. >> >> Norbert >> >> > If it's dynamic, we could also trace which particular change in the Kernel > is causing a regression in a package, and that would be a GOOD thing. > > I mean GOOD both for kernel developers (knowing how many packages you broke with a single API change might introduce some stiffness/damping in the change for changing policy) and package developpers (this can help localizing exactly which API was deprecated/changed) > But do we still want to have a right to temporarily break things in the > kernel image, or should we tend to a continuous integration? In the former > case, the pace of 2.0->3.0 change rate might generate a lot of noise ;) > > >> You just remind me to give gitfiletree another try. >> >> >> On Wed, May 28, 2014 at 10:56 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: >> >>> There havenât as far as I know. But "I trust everyone. It's the devil >>> inside them I don't trustâ. I really like the workflow that emerged from >>> git and github. If one wants to contribute, he forks project, makes changes >>> and submits a pull request. Then you analyse changes made and either merge >>> them into the project, or not (also pull request can be priorly checked by >>> CI and so on). Now if you have have something completely âopenâ it means >>> that you trust all the world, and I would say that itâs not a good thing to >>> do. Yes, inbox is not Pharo repository. But still. >>> >>> Uko >>> >>> >>> On 28 May 2014, at 09:37, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> I dont see a big problem not having MetaRepoForPharo4 as public access , >>> its not as if anyone will plant a pharo virus anytime soon and if a mistake >>> is done, its not the end of the world , people can fix it if they find so >>> annoying. Have there been any major issues so far with public access ? >>> >>> >>> On Wed, May 28, 2014 at 10:28 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: >>> >>>> >>>> On 28 May 2014, at 09:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> > >>>> > >>>> >> Am 28.05.2014 um 08:47 schrieb Marcus Denker <marcus.denker(a)inria.fr >>>> >: >>>> >> >>>> >> >>>> >>> On 28 May 2014, at 03:17, Gabriel Cotelli <g.cotelli(a)gmail.com> >>>> wrote: >>>> >>> >>>> >>> Hi, >>>> >>> is the Meta Repo for Pharo 4 ready to use? >>>> >>> >>>> >>> I've configured my jobs in the contribution ci server to run also >>>> for Pharo 4. But I can't copy the configuration to the meta repo for Pharo >>>> 4 to make it available in the Configuration Browser. >>>> >>> Maybe some permissions are missing? >>>> >>> >>>> >> >>>> >> Yes, public write access was missingâ¦ I added that for now, but of >>>> course the question is: do we really want it to be writable by everyone? >>>> > >>>> > No! And I would also want only configs to be put into the meta repo >>>> that build green. So basically only the pharo contributions CI should >>>> upload configs. But I can see that this might be too much effort and >>>> restriction. >>>> > >>>> > Norbert >>>> >>>> We just need a better infrastructure. Look at ATOM project. 1) >>>> contributions are made with pull requests 2) they have a dedicated apm tool >>>> for package submission/management. With monticello weâve achieved the best >>>> we can. And I guess we donât have enough resources to build and maintain >>>> new tools. >>>> >>>> Uko >>>> >>> >>> >>> >> >> >

May 28, 2014

Re: [Pharo-dev] MetaRepoForPharo40

by Nicolas Cellier

2014-05-28 10:26 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 28.05.2014 um 10:08 schrieb kilon alios <kilon.alios(a)gmail.com>: > > Well I am a big fan of github and git myself. Though I also love > smalltalkhub , so far I had no serious issues with it apart from the site > going down at times and not being able to browser new projects. > > The thing with public access is that you don't worry about it unless a > problem occurs. Which saves time and is less demanding on the maintenance > side. I will have to agree that github repo with pull requests would be > ideal. None the less , things look that are moving towards a better > direction :) > > You can have public access in each individual project. Iâm just saying > that the configuration of a project is only copied to _the_ pharo software > catalog if it isnât broken. So while everyone has public access to a > project and there is an automatic build on a CI the configuration will be > arrive in the meta repo sooner or later. No one has to do anything. > If public access would the best way to go pull requests wouldnât be so > prominent. It is a solution to let people easily participate without having > access to a repository. > > Norbert > > If it's dynamic, we could also trace which particular change in the Kernel is causing a regression in a package, and that would be a GOOD thing. But do we still want to have a right to temporarily break things in the kernel image, or should we tend to a continuous integration? In the former case, the pace of 2.0->3.0 change rate might generate a lot of noise ;) > You just remind me to give gitfiletree another try. > > > On Wed, May 28, 2014 at 10:56 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: > >> There havenât as far as I know. But "I trust everyone. It's the devil >> inside them I don't trustâ. I really like the workflow that emerged from >> git and github. If one wants to contribute, he forks project, makes changes >> and submits a pull request. Then you analyse changes made and either merge >> them into the project, or not (also pull request can be priorly checked by >> CI and so on). Now if you have have something completely âopenâ it means >> that you trust all the world, and I would say that itâs not a good thing to >> do. Yes, inbox is not Pharo repository. But still. >> >> Uko >> >> >> On 28 May 2014, at 09:37, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I dont see a big problem not having MetaRepoForPharo4 as public access , >> its not as if anyone will plant a pharo virus anytime soon and if a mistake >> is done, its not the end of the world , people can fix it if they find so >> annoying. Have there been any major issues so far with public access ? >> >> >> On Wed, May 28, 2014 at 10:28 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: >> >>> >>> On 28 May 2014, at 09:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> > >>> > >>> >> Am 28.05.2014 um 08:47 schrieb Marcus Denker <marcus.denker(a)inria.fr >>> >: >>> >> >>> >> >>> >>> On 28 May 2014, at 03:17, Gabriel Cotelli <g.cotelli(a)gmail.com> >>> wrote: >>> >>> >>> >>> Hi, >>> >>> is the Meta Repo for Pharo 4 ready to use? >>> >>> >>> >>> I've configured my jobs in the contribution ci server to run also >>> for Pharo 4. But I can't copy the configuration to the meta repo for Pharo >>> 4 to make it available in the Configuration Browser. >>> >>> Maybe some permissions are missing? >>> >>> >>> >> >>> >> Yes, public write access was missingâ¦ I added that for now, but of >>> course the question is: do we really want it to be writable by everyone? >>> > >>> > No! And I would also want only configs to be put into the meta repo >>> that build green. So basically only the pharo contributions CI should >>> upload configs. But I can see that this might be too much effort and >>> restriction. >>> > >>> > Norbert >>> >>> We just need a better infrastructure. Look at ATOM project. 1) >>> contributions are made with pull requests 2) they have a dedicated apm tool >>> for package submission/management. With monticello weâve achieved the best >>> we can. And I guess we donât have enough resources to build and maintain >>> new tools. >>> >>> Uko >>> >> >> >> > >

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Goubier Thierry

Le 28/05/2014 11:16, phil(a)highoctane.be a Ã©crit : > Hi Thierry, > > On Wed, May 28, 2014 at 10:44 AM, Goubier Thierry > <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: > > > On which platform are you commiting / merging ? This looks strange: > .st files should be multi-line, not one line. > > > CentOS 6 Linux Well, have you set any strange options in the git repository itself? I've seen in the man pages stuff about automatic line ending conversions. > What is the current best practice for merging packages that way? > > > As others said, probably the best is the GitFileTree-MergeDriver to > minimize conflicts with FileTree Monticello metadata, but I'd say > it's complex to setup at the moment, and the git mergetool that Dale > has in ToDe (to avoid using meld :)) > > > Yeah, meld here... Or vimdiff At least there is a tool :) > > I'm trying to find the time to document and set a sample git repo in > the PharoForTheEnterprise book with all the different ways to merge: > > - pure FileTree > - FileTree + GitFileTree merge driver > - GitFileTree + binary merge on metadata > - GitFileTree + GitFileTree merge driver > > But I'm not finding the time I need to finish that :( > > > Mmmh, anything not even close to a draft and some notes are welcome! I haven't yet set it to generates the chapter, but it is the GitAndPharo chapter (and I have a GitAndPharoTutorial repository on github to go along, with pre-prepared branches to let people experiment the merge). > I'll be presenting that during the next MooseDay, so it can be an > occasion to talk. > > > Yeah, I think that I can come over for the first day to listen you that > Git talk of yours and show you our thing. Cool. It'll be a pleasure :) Thierry > BTW http://www.doesnotunderstand.org/MOOSEDayUPMC/ says "Thuesday". I do > not know what "Thuesday" means, but as the next day looks like "Friday", > I'd advise someone put "Thursday" (or is it Tuesday after all?). > > > Schedule > > Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod > tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. > > > looks weird too. > > Phil > > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 28, 2014

Re: [Pharo-dev] MetaRepoForPharo40

by Torsten Bergmann

Hi, Â 1. MetaRepoForPharo40 is working - I tried with Pomodoro Â 2.Â The idea of the repo is to provide stable and working version for "end-users" on top of aÂ Â Â Pharo stable release. So currently we should fill "MetaRepoForPharo30" for 3.0 as this is the stable release andÂ not yet "MetaRepoForPharo40" as Pharo 4.0 now just starts. Â 3. While by default the config browser in Pharo 4.0 will open it's according "MetaRepoForPharo40" it is possible to switch to other older repos in the context menu.Â Â It should be possible to switch also to the "MetaRepoForPharo30" in the context menu. Â Â This is fixed inÂ https://pharo.fogbugz.com/f/cases/13279 and should be integrated for Pharo 4 Â Bye T. Â Â

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by phil＠highoctane.be

Hi Thierry, On Wed, May 28, 2014 at 10:44 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Hi Phil, > > Le 27/05/2014 20:38, phil(a)highoctane.be a Ã©crit : > >> Hello, >> >> I am working with Sebastian on some code and we tried out filetree:// >> >> We have our packages saved there on disk and then we commit/push them on >> the git server. >> >> Now, as we develop and then need to merge, I find it hard to do those >> merges on the .st files. >> >> As ^M is used as separator, the merge tools seem to have a difficult >> time and show us 2 huge lines. >> > > On which platform are you commiting / merging ? This looks strange: .st > files should be multi-line, not one line. > CentOS 6 Linux > > What is the current best practice for merging packages that way? >> > > As others said, probably the best is the GitFileTree-MergeDriver to > minimize conflicts with FileTree Monticello metadata, but I'd say it's > complex to setup at the moment, and the git mergetool that Dale has in ToDe > (to avoid using meld :)) > Yeah, meld here... Or vimdiff > > I'm trying to find the time to document and set a sample git repo in the > PharoForTheEnterprise book with all the different ways to merge: > > - pure FileTree > - FileTree + GitFileTree merge driver > - GitFileTree + binary merge on metadata > - GitFileTree + GitFileTree merge driver > > But I'm not finding the time I need to finish that :( > Mmmh, anything not even close to a draft and some notes are welcome! > I'll be presenting that during the next MooseDay, so it can be an occasion > to talk. Yeah, I think that I can come over for the first day to listen you that Git talk of yours and show you our thing. BTW http://www.doesnotunderstand.org/MOOSEDayUPMC/ says "Thuesday". I do not know what "Thuesday" means, but as the next day looks like "Friday", I'd advise someone put "Thursday" (or is it Tuesday after all?). Schedule Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. looks weird too. Phil > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Nicolas Cellier

2014-05-28 10:44 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr>: > Hi Phil, > > Le 27/05/2014 20:38, phil(a)highoctane.be a Ã©crit : > > Hello, >> >> I am working with Sebastian on some code and we tried out filetree:// >> >> We have our packages saved there on disk and then we commit/push them on >> the git server. >> >> Now, as we develop and then need to merge, I find it hard to do those >> merges on the .st files. >> >> As ^M is used as separator, the merge tools seem to have a difficult >> time and show us 2 huge lines. >> > > On which platform are you commiting / merging ? This looks strange: .st > files should be multi-line, not one line. > > I've patched MC model (MethodDefinition and class comments) with a few withSqueakLineEndings (sorry Pharoers for the Squeakism) to just ignore the line ending differences. Maybe I should publish, but my feeling was that there should be a better place (upstream) for this... > What is the current best practice for merging packages that way? >> > > As others said, probably the best is the GitFileTree-MergeDriver to > minimize conflicts with FileTree Monticello metadata, but I'd say it's > complex to setup at the moment, and the git mergetool that Dale has in ToDe > (to avoid using meld :)) > > I'm trying to find the time to document and set a sample git repo in the > PharoForTheEnterprise book with all the different ways to merge: > > - pure FileTree > - FileTree + GitFileTree merge driver > - GitFileTree + binary merge on metadata > - GitFileTree + GitFileTree merge driver > > But I'm not finding the time I need to finish that :( > > I'll be presenting that during the next MooseDay, so it can be an occasion > to talk. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Goubier Thierry

Le 27/05/2014 22:19, Esteban Lorenzano a Ã©crit : > > On 27 May 2014, at 17:09, phil(a)highoctane.be <mailto:phil@highoctane.be> > wrote: > >> On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com >> <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> >> >> 2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be >> <mailto:johan@inceptive.be>>: >> >> Have you tried this? >> >> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >> >> Not sure about the ^M problem though... >> >> Johan >> >> >> I second this, with GitFileTree it solves most problems of false >> conflicts caused by MC metadata. >> For true conflicts, I did not inquire. >> >> >> Ok, will have a look. >> >> At first sight, it looks scary and less friendly than a plain old MCZ >> merge. >> >> But... git is the standard and it is painful to have to maintain >> things in two placesâ¦ > > filetree format is buggy when merging. Reason is is keeping monticello > metadata and that does not plays very good with git (bah, it does not > play good at all). This is in no part due to the fact that we don't set up git to play nice with this metadata... > We are working (Max is doing some work there) in a better integration > with git, where we can drop all those metadata files and rely on git > information (it is there, we just need to use it). But as always, things > needs time and time is scarce :(. Yes. I'm expecting a lot from that project, even if I'm not sure about that "removing the metadata" stuff. Using git as the source of the metadata isn't hard. > My recommendation in the mean time is to try gitfiletree. There is a > good chance that it fixes your problems. It has issues with the merge conflicts, still. Hence the talk about the merge driver and the merge tool. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Goubier Thierry

Le 27/05/2014 23:48, Dale Henrichs a Ã©crit : > Johan, > > From the GemStone side, tODE has a number of git-friendly features and > will be available for alpha real-soon-now[TM] ... > > I use the tODE git merge tool for all of my git merges as I consider it > superior to the existing mergetools out there ... but then I'm biased:) > > I'm willing to share the fundamental classes for parsing the git > merge/diff information if folks from Pharo want to get into that > business ... Cool. I'm for it :) > the Metacello Preview features have also been aimed at support for > git-based development and I'm leveraging those features for tODE as well ... > Dale Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Goubier Thierry

Hi Phil, Le 27/05/2014 20:38, phil(a)highoctane.be a Ã©crit : > Hello, > > I am working with Sebastian on some code and we tried out filetree:// > > We have our packages saved there on disk and then we commit/push them on > the git server. > > Now, as we develop and then need to merge, I find it hard to do those > merges on the .st files. > > As ^M is used as separator, the merge tools seem to have a difficult > time and show us 2 huge lines. On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line. > What is the current best practice for merging packages that way? As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :)) I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge: - pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver But I'm not finding the time I need to finish that :( I'll be presenting that during the next MooseDay, so it can be an occasion to talk. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 28, 2014

Re: [Pharo-dev] MetaRepoForPharo40

by stepharo

> No! And I would also want only configs to be put into the meta repo that build green. So basically only the pharo contributions CI should upload configs. But I can see that this might be too much effort and restriction. I agree and we proposed to get an engineer to automate this task but it was declined. Any help on that would be welcome. Stef

May 28, 2014