August 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by StÃ©phane Ducasse

>> >> > > That's exactly what i was thinking about when registered cog issue tracker. > And since Cog used not just by Pharo, it deserves own separate repository. > > Now i would like to know, if somebody asked people who contributing to Cog > development but not to Pharo, if they would like to use Pharo issue > tracker for that. > > Or maybe we don't have to care, then doing like this is a way to piss them off. Indeed this is the drawback. So when we close something on pharo and that it contributes to cog we should update the cog one. > > > -- > Best regards, > Igor Stasenko. >

Aug. 7, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 7 August 2013 19:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 6:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 >>> >>> They are under the Pharo-VM project. >>> >>> That way we can handle them easily. >>> >> >> I don't like this move. > > why > > having everything in a single place is good. > That's exactly what i was thinking about when registered cog issue tracker. And since Cog used not just by Pharo, it deserves own separate repository. Now i would like to know, if somebody asked people who contributing to Cog development but not to Pharo, if they would like to use Pharo issue tracker for that. Or maybe we don't have to care, then doing like this is a way to piss them off. -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fwd: Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > now can we get a working keyboard? Yes here Hi, Guille built a new vm with an attept of fixing the key combinations problem. Can you test it? http://files.pharo.org/vm/pharo/ (and pick the latest for your platform) Thanks, Esteban > > On Wednesday, August 7, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Agree with everything you said. > > As i said, my impression was that Guille pushed unfininowshed/incomplete pieces. > > And that is what i against. > > Because if we go that way, then someone will start pushing changes > > which even don't compile. > > > > I hope i made my point clear, what blessed means. It is not synonym > > to 'stable'. > > > > > > On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). > >> Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). > >> > >> VM development is not stable right now, same way it is not stable 3.0 > >> Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). > >> Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. > >> But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. > >> > >> So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. > >> > >> Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. > >> For that, what we should have is: > >> - all sources in just one repository, including vmmaker (I'm working on that) > >> - create a tag (that we can branch and backport stuff) each release. > >> > >> no need to stress about :) > >> > >> my 2c > >> > >> Esteban > >> > >> > >> On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >>> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >>>> > >>>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>>>> > >>>>> My understanding how it should be: > >>>>> - you work in own branch (and in git, repository clone is already a > >>>>> branch, just on your computer). > >>>>> If you want to make it public you need to make own branch on gitorious > >>>>> and commit there. > >>>>> - once you finished with changes and tested it , you are free to merge > >>>>> with blessed > >>>>> (no need to have GODs permission to do that, or make pull requests) > >>>> > >>>> > >>>> We did all that. We tested it with Ben because he needed the change to send > >>>> ctrl events from the vm to the image, which were not sent. We tested in our > >>>> computers, and we had no much trouble. > >>>> > >>>> - I do not use delete key because I don't have one > >>>> - circumflex accent (return) was working with my keyboard layout > >>>> > >>>> So the vm was to me in a completely usable state. > >>>> > >>>>> > >>>>> > >>>>> now i understand we are humans and not immune to mistakes, but i > >>>>> insist that committing to blessed > >>>> > >>>> > >>>> 'blessed' is a crappy name for a repository. And the idea that the code in > >>>> this repository is always working flawlessly is nonsense. For example, we > >>>> had for months the problem with the smallinteger in there. > >>>> > >>>> And then, the unstable is in another repository then? Where is that > >>>> repository? Why do we have to make another repository for that and not just > >>>> a branch (in the same repo, not in my machine)? > >>>> > >>> > >>> so what you proposing? lets everyone put own unfinished changes into > >>> same repository > >>> without synchronization and see how it flies? > >>> it won't fly, i can tell you even without trying. > >>> > >>>>> > >>>>> should be done after some manual testing and checking it don't breaks > >>>>> things badly, and of course > >>>>> blessed is not for committing the unfinished code , which in the > >>>>> middle of work. > >>>> > >>>> > >>>> First, we considered it as finished. What you found was a bug, not a pending > >>>> to do task. > >>>> > >>> > >>> Ah, in that case it is perfectly ok then. > >>> It is your messages in previous mails gave me impression that > > -- > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Featured on the Software Process and Measurement Cast > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > >

Aug. 7, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by StÃ©phane Ducasse

On Aug 7, 2013, at 6:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 >> >> They are under the Pharo-VM project. >> >> That way we can handle them easily. >> > > I don't like this move. why having everything in a single place is good. > If moving issues from one > tracker to another would help fixing them in some magical way, i would > be doing this every day. > > > >> Guille > > > -- > Best regards, > Igor Stasenko. >

Aug. 7, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 > > They are under the Pharo-VM project. > > That way we can handle them easily. > I don't like this move. If moving issues from one tracker to another would help fixing them in some magical way, i would be doing this every day. > Guille -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fwd: Keyboard events is broken.

by phil＠highoctane.be

now can we get a working keyboard? On Wednesday, August 7, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: > Agree with everything you said. > As i said, my impression was that Guille pushed unfininowshed/incomplete pieces. > And that is what i against. > Because if we go that way, then someone will start pushing changes > which even don't compile. > > I hope i made my point clear, what blessed means. It is not synonym > to 'stable'. > > > On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). >> Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). >> >> VM development is not stable right now, same way it is not stable 3.0 >> Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). >> Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. >> But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. >> >> So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. >> >> Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. >> For that, what we should have is: >> - all sources in just one repository, including vmmaker (I'm working on that) >> - create a tag (that we can branch and backport stuff) each release. >> >> no need to stress about :) >> >> my 2c >> >> Esteban >> >> >> On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>> My understanding how it should be: >>>>> - you work in own branch (and in git, repository clone is already a >>>>> branch, just on your computer). >>>>> If you want to make it public you need to make own branch on gitorious >>>>> and commit there. >>>>> - once you finished with changes and tested it , you are free to merge >>>>> with blessed >>>>> (no need to have GODs permission to do that, or make pull requests) >>>> >>>> >>>> We did all that. We tested it with Ben because he needed the change to send >>>> ctrl events from the vm to the image, which were not sent. We tested in our >>>> computers, and we had no much trouble. >>>> >>>> - I do not use delete key because I don't have one >>>> - circumflex accent (return) was working with my keyboard layout >>>> >>>> So the vm was to me in a completely usable state. >>>> >>>>> >>>>> >>>>> now i understand we are humans and not immune to mistakes, but i >>>>> insist that committing to blessed >>>> >>>> >>>> 'blessed' is a crappy name for a repository. And the idea that the code in >>>> this repository is always working flawlessly is nonsense. For example, we >>>> had for months the problem with the smallinteger in there. >>>> >>>> And then, the unstable is in another repository then? Where is that >>>> repository? Why do we have to make another repository for that and not just >>>> a branch (in the same repo, not in my machine)? >>>> >>> >>> so what you proposing? lets everyone put own unfinished changes into >>> same repository >>> without synchronization and see how it flies? >>> it won't fly, i can tell you even without trying. >>> >>>>> >>>>> should be done after some manual testing and checking it don't breaks >>>>> things badly, and of course >>>>> blessed is not for committing the unfinished code , which in the >>>>> middle of work. >>>> >>>> >>>> First, we considered it as finished. What you found was a bug, not a pending >>>> to do task. >>>> >>> >>> Ah, in that case it is perfectly ok then. >>> It is your messages in previous mails gave me impression that -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Aug. 7, 2013

Put issues from cog issue tracker into pharo issue tracker

by Guillermo Polito

https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 They are under the Pharo-VM project. That way we can handle them easily. Guille

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

Agree with everything you said. As i said, my impression was that Guille pushed unfinished/incomplete pieces. And that is what i against. Because if we go that way, then someone will start pushing changes which even don't compile. I hope i made my point clear, what blessed means. It is not synonym to 'stable'. On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). > Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). > > VM development is not stable right now, same way it is not stable 3.0 > Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). > Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. > But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. > > So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. > > Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. > For that, what we should have is: > - all sources in just one repository, including vmmaker (I'm working on that) > - create a tag (that we can branch and backport stuff) each release. > > no need to stress about :) > > my 2c > > Esteban > > > On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> My understanding how it should be: >>>> - you work in own branch (and in git, repository clone is already a >>>> branch, just on your computer). >>>> If you want to make it public you need to make own branch on gitorious >>>> and commit there. >>>> - once you finished with changes and tested it , you are free to merge >>>> with blessed >>>> (no need to have GODs permission to do that, or make pull requests) >>> >>> >>> We did all that. We tested it with Ben because he needed the change to send >>> ctrl events from the vm to the image, which were not sent. We tested in our >>> computers, and we had no much trouble. >>> >>> - I do not use delete key because I don't have one >>> - circumflex accent (return) was working with my keyboard layout >>> >>> So the vm was to me in a completely usable state. >>> >>>> >>>> >>>> now i understand we are humans and not immune to mistakes, but i >>>> insist that committing to blessed >>> >>> >>> 'blessed' is a crappy name for a repository. And the idea that the code in >>> this repository is always working flawlessly is nonsense. For example, we >>> had for months the problem with the smallinteger in there. >>> >>> And then, the unstable is in another repository then? Where is that >>> repository? Why do we have to make another repository for that and not just >>> a branch (in the same repo, not in my machine)? >>> >> >> so what you proposing? lets everyone put own unfinished changes into >> same repository >> without synchronization and see how it flies? >> it won't fly, i can tell you even without trying. >> >>>> >>>> should be done after some manual testing and checking it don't breaks >>>> things badly, and of course >>>> blessed is not for committing the unfinished code , which in the >>>> middle of work. >>> >>> >>> First, we considered it as finished. What you found was a bug, not a pending >>> to do task. >>> >> >> Ah, in that case it is perfectly ok then. >> It is your messages in previous mails gave me impression that it is >> 'not done yet' >> but 'work in progress' and change is not finished. >> >>> Second, I have not the time to change to and learn every keyboard layout to >>> test, nor to plug every external keyboard and see how it behaves. So if you >>> think we should have done that, it will never be finished, and we will die >>> with what we have. >>> >>> Third, we need an unstable official branch for the pharo vm code for people >>> to test. To me, as blessed is the only repository out there, it is the only >>> place where I can put it. >>> >> >> It is blessed in terms that every change you pushing there is blessed >> by you (as developer), >> which means "i recommend to use new version by others". >> And until you can bless your own changes you should not push them into >> this repository, >> while obviously you free to push/commit them elsewhere. >> >>>> >>>> >>>> That is my only issue , that you committed code which is not yet >>>> finished, and makes VM unusable, >>> >>> >>> Now again. To me the latest vm was completely usable. How can I prove that >>> the change is then finished if I do not test with every existing device and >>> layout? >>> >>> So people has to test it. And let's be realistic: given the few people using >>> nowadays the latest pharo vm, if I put my code in my own personal >>> repository, how many people will download my experimental VM to test it from >>> my hidden branch in my hidden and personal repo? I guess almost none. >>> >>> No one tests => never proved => never finished => never merged => dies >>> >> Agreed. >> >>> That does not work. >>> >>> So if bleesed is the stable branch, which is the latest unstable branch? Do >>> we need many repositories for that? >>> >> >> it is not stable branch, it is development. >> stable versions come time to time, we can tag them as stable. >> >>>> and we cannot release VM with important fix to smallinteger bug before >>>> you finish, which turns yourself >>>> into a bottleneck. >>> >>> >>> You can always go to the vm log >>> >>> https://gitorious.org/cogvm/blessed/commits/master >>> >>> and check my last commits and try to rollback them in any case. This change >>> was only two lines of code. I'm of course not the code owner. >>> >>> >>> Now, I'm tired to argue. I want to solve this by stating: >>> - how do we get the latest unstable and where should the code be >>> - how do we get the latest stable and where should the code be >>> >>> Something else is that I have the feeling that we are discussing because of >>> the stupid "blessed" name. So I did this: >>> - create a new pharovm repo inside https://gitorious.org/cogvm, the old >>> blessed repo stays the same >>> - I copied everything from the repo blessed to pharovm, including history >>> - I created a blessed branch, which should in the future have the properties >>> you like <=> latest stable >>> - let master for latest bleedingEdge (not experimental, but maybe buggy) >>> >>> And then if we want other branches we create them. >>> >>> https://gitorious.org/cogvm/pharovm >> >> just one question: why adding 'blessed' branch if you think it is stupid? >> name it stable then, since you don't understand/value of blessing or >> consider it is stupid >> and unnecessary. >> but again, we don't need 'stable' as separate branch.. makes little sense, >> since we can just tag certain versions as stable, like everyone else does. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Please test: New PharoVM built

by Igor Stasenko

me too. On 7 August 2013 13:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks I will try it now. > > Stef > On Aug 7, 2013, at 1:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> Guille built a new vm with an attept of fixing the key combinations problem. >> Can you test it? >> >> http://files.pharo.org/vm/pharo/ >> >> (and pick the latest for your platform) >> >> Thanks, >> Esteban >> >> > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). VM development is not stable right now, same way it is not stable 3.0 Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. For that, what we should have is: - all sources in just one repository, including vmmaker (I'm working on that) - create a tag (that we can branch and backport stuff) each release. no need to stress about :) my 2c Esteban On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> My understanding how it should be: >>> - you work in own branch (and in git, repository clone is already a >>> branch, just on your computer). >>> If you want to make it public you need to make own branch on gitorious >>> and commit there. >>> - once you finished with changes and tested it , you are free to merge >>> with blessed >>> (no need to have GODs permission to do that, or make pull requests) >> >> >> We did all that. We tested it with Ben because he needed the change to send >> ctrl events from the vm to the image, which were not sent. We tested in our >> computers, and we had no much trouble. >> >> - I do not use delete key because I don't have one >> - circumflex accent (return) was working with my keyboard layout >> >> So the vm was to me in a completely usable state. >> >>> >>> >>> now i understand we are humans and not immune to mistakes, but i >>> insist that committing to blessed >> >> >> 'blessed' is a crappy name for a repository. And the idea that the code in >> this repository is always working flawlessly is nonsense. For example, we >> had for months the problem with the smallinteger in there. >> >> And then, the unstable is in another repository then? Where is that >> repository? Why do we have to make another repository for that and not just >> a branch (in the same repo, not in my machine)? >> > > so what you proposing? lets everyone put own unfinished changes into > same repository > without synchronization and see how it flies? > it won't fly, i can tell you even without trying. > >>> >>> should be done after some manual testing and checking it don't breaks >>> things badly, and of course >>> blessed is not for committing the unfinished code , which in the >>> middle of work. >> >> >> First, we considered it as finished. What you found was a bug, not a pending >> to do task. >> > > Ah, in that case it is perfectly ok then. > It is your messages in previous mails gave me impression that it is > 'not done yet' > but 'work in progress' and change is not finished. > >> Second, I have not the time to change to and learn every keyboard layout to >> test, nor to plug every external keyboard and see how it behaves. So if you >> think we should have done that, it will never be finished, and we will die >> with what we have. >> >> Third, we need an unstable official branch for the pharo vm code for people >> to test. To me, as blessed is the only repository out there, it is the only >> place where I can put it. >> > > It is blessed in terms that every change you pushing there is blessed > by you (as developer), > which means "i recommend to use new version by others". > And until you can bless your own changes you should not push them into > this repository, > while obviously you free to push/commit them elsewhere. > >>> >>> >>> That is my only issue , that you committed code which is not yet >>> finished, and makes VM unusable, >> >> >> Now again. To me the latest vm was completely usable. How can I prove that >> the change is then finished if I do not test with every existing device and >> layout? >> >> So people has to test it. And let's be realistic: given the few people using >> nowadays the latest pharo vm, if I put my code in my own personal >> repository, how many people will download my experimental VM to test it from >> my hidden branch in my hidden and personal repo? I guess almost none. >> >> No one tests => never proved => never finished => never merged => dies >> > Agreed. > >> That does not work. >> >> So if bleesed is the stable branch, which is the latest unstable branch? Do >> we need many repositories for that? >> > > it is not stable branch, it is development. > stable versions come time to time, we can tag them as stable. > >>> and we cannot release VM with important fix to smallinteger bug before >>> you finish, which turns yourself >>> into a bottleneck. >> >> >> You can always go to the vm log >> >> https://gitorious.org/cogvm/blessed/commits/master >> >> and check my last commits and try to rollback them in any case. This change >> was only two lines of code. I'm of course not the code owner. >> >> >> Now, I'm tired to argue. I want to solve this by stating: >> - how do we get the latest unstable and where should the code be >> - how do we get the latest stable and where should the code be >> >> Something else is that I have the feeling that we are discussing because of >> the stupid "blessed" name. So I did this: >> - create a new pharovm repo inside https://gitorious.org/cogvm, the old >> blessed repo stays the same >> - I copied everything from the repo blessed to pharovm, including history >> - I created a blessed branch, which should in the future have the properties >> you like <=> latest stable >> - let master for latest bleedingEdge (not experimental, but maybe buggy) >> >> And then if we want other branches we create them. >> >> https://gitorious.org/cogvm/pharovm > > just one question: why adding 'blessed' branch if you think it is stupid? > name it stable then, since you don't understand/value of blessing or > consider it is stupid > and unnecessary. > but again, we don't need 'stable' as separate branch.. makes little sense, > since we can just tag certain versions as stable, like everyone else does. > > > -- > Best regards, > Igor Stasenko. >

Aug. 7, 2013