Re: [Pharo-project] did you check in 1.1 how the old browser now support the creation of new method cat
I sent that to the list because this is really important.
one of these days we will have to have some pharo specific tools.
There will be nobody that maintains them. There will be nobody that takes responsibility and that writes and runs tests. You can see that with Davids browser, it is dead. You can see that with Services, they are dead. And many others ...
Yes but pharo is moving so slowly we will get more people taking care of packages.
But that is not the real problem. And I didn't mean Squeak (although that's a problem too, but I personally don't care). What I ment is the difference between Pharo 1.0 and Pharo 1.1.
You lost me there :)
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I spent the complete Thursday and Friday trying to get Helvetia running in Pharo 1.1, but that doesn't work because it requires some significant changes in packages like the Refactoring Rngine, the AST, Shout, eCompletion and OB that are also supposed to work on Pharo 1.0.
No there are not supposed to work in 1.0 CERTAIN frozen versions are supposed to work on 1.0 and others won't. A lot of software on mac does not run automatically on snowleopard and 10.2 Tell me if Im wrong but we should use release and version.
Adding the category dialog to OB makes it depend on 1.1, thus people cannot use it in 1.0 anymore. So the category dialog can maybe happen in a year from now. I cannot use 1.1 at the moment, I am stuck with the frozen 1.0 version.
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I want to use the latest tools, but a stable base system. If I cannot count on a stable base, I cannot do fancy stuff on top. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi, can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work) Thanks Hernán 2009/12/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I sent that to the list because this is really important.
one of these days we will have to have some pharo specific tools.
There will be nobody that maintains them. There will be nobody that takes responsibility and that writes and runs tests. You can see that with Davids browser, it is dead. You can see that with Services, they are dead. And many others ...
Yes but pharo is moving so slowly we will get more people taking care of packages.
But that is not the real problem. And I didn't mean Squeak (although that's a problem too, but I personally don't care). What I ment is the difference between Pharo 1.0 and Pharo 1.1.
You lost me there :)
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I spent the complete Thursday and Friday trying to get Helvetia running in Pharo 1.1, but that doesn't work because it requires some significant changes in packages like the Refactoring Rngine, the AST, Shout, eCompletion and OB that are also supposed to work on Pharo 1.0.
No there are not supposed to work in 1.0 CERTAIN frozen versions are supposed to work on 1.0 and others won't. A lot of software on mac does not run automatically on snowleopard and 10.2
Tell me if Im wrong but we should use release and version.
Adding the category dialog to OB makes it depend on 1.1, thus people cannot use it in 1.0 anymore. So the category dialog can maybe happen in a year from now. I cannot use 1.1 at the moment, I am stuck with the frozen 1.0 version.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work)
Pharo 1.0rc1 is basically frozen. The unstable moving target is 1.1. The same here, I cannot maintain versions for 1.0 and 1.1. Also I cannot freeze my tools for 1.0, because I need to change them and want to use them on a stable base. AST and RB should now work in both, but it was a significant amount of work. I cannot keep RB, OB, Seaside, Pier, Magritte, PetitParser, SmaCC, ... running on all versions and will concentrate on 1.0 for now, keeping in mind upcoming changes for the next unstable versions. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 20, 2009, at 7:39 PM, Lukas Renggli wrote:
can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work)
Pharo 1.0rc1 is basically frozen. The unstable moving target is 1.1.
The same here, I cannot maintain versions for 1.0 and 1.1. Also I cannot freeze my tools for 1.0, because I need to change them and want to use them on a stable base.
AST and RB should now work in both, but it was a significant amount of work. I cannot keep RB, OB, Seaside, Pier, Magritte, PetitParser, SmaCC, ... running on all versions and will concentrate on 1.0 for now, keeping in mind upcoming changes for the next unstable versions.
Yes this is reasonable. I do not see why this would be different without having to maintain two branches. Or it means that the core does not change. (which I hope will happen in the future but not for now). Stef
Version 1.0 is the one to work with, to build and maintain tools for, etc. Unless you work on the Pharo base system there is no good reason to use 1.1 at the current time. It is unstable and it is going to change. Furthermore, nobody can expect that external packages are already flawlessly working with the moving target 1.1. At a later point when 1.1 is getting stable it makes sense to move over from 1.0 and make your packages, applications etc. work with the new version. I don't know the details and context of the discussion that Stef posted. But I assume that it also concerns packages that are in Pharo (i.e., packages that are added to PharoCore). There we have a slightly different situation because these packages are part of the Pharo image and hence also need to follow its release regime. That is, for the release of Pharo 1.0, the added packages need to be in a stable state. The versions of the packages used in Pharo should not add new features since post release 1.0 there should only be few updates for critical fixes. Adrian On Dec 20, 2009, at 19:16 , Hernán Morales Durand wrote:
Hi, can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work) Thanks
Hernán
2009/12/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I sent that to the list because this is really important.
one of these days we will have to have some pharo specific tools.
There will be nobody that maintains them. There will be nobody that takes responsibility and that writes and runs tests. You can see that with Davids browser, it is dead. You can see that with Services, they are dead. And many others ...
Yes but pharo is moving so slowly we will get more people taking care of packages.
But that is not the real problem. And I didn't mean Squeak (although that's a problem too, but I personally don't care). What I ment is the difference between Pharo 1.0 and Pharo 1.1.
You lost me there :)
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I spent the complete Thursday and Friday trying to get Helvetia running in Pharo 1.1, but that doesn't work because it requires some significant changes in packages like the Refactoring Rngine, the AST, Shout, eCompletion and OB that are also supposed to work on Pharo 1.0.
No there are not supposed to work in 1.0 CERTAIN frozen versions are supposed to work on 1.0 and others won't. A lot of software on mac does not run automatically on snowleopard and 10.2
Tell me if Im wrong but we should use release and version.
Adding the category dialog to OB makes it depend on 1.1, thus people cannot use it in 1.0 anymore. So the category dialog can maybe happen in a year from now. I cannot use 1.1 at the moment, I am stuck with the frozen 1.0 version.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian lukas was frustrated because he could not have the last version of the tools like RB, helvetia working in 1.1 and 1.0 I think that this is not something that you can expect. Else we can just stop Pharo now and go to do something else. This is why tools should work on a stable version and be marked tools for Pharo1.0 and brnaching to have tools for pharo1.1 Stef On Dec 20, 2009, at 7:53 PM, Adrian Lienhard wrote:
Version 1.0 is the one to work with, to build and maintain tools for, etc. Unless you work on the Pharo base system there is no good reason to use 1.1 at the current time. It is unstable and it is going to change. Furthermore, nobody can expect that external packages are already flawlessly working with the moving target 1.1. At a later point when 1.1 is getting stable it makes sense to move over from 1.0 and make your packages, applications etc. work with the new version.
I don't know the details and context of the discussion that Stef posted. But I assume that it also concerns packages that are in Pharo (i.e., packages that are added to PharoCore). There we have a slightly different situation because these packages are part of the Pharo image and hence also need to follow its release regime. That is, for the release of Pharo 1.0, the added packages need to be in a stable state. The versions of the packages used in Pharo should not add new features since post release 1.0 there should only be few updates for critical fixes.
Adrian
On Dec 20, 2009, at 19:16 , Hernán Morales Durand wrote:
Hi, can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work) Thanks
Hernán
2009/12/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I sent that to the list because this is really important.
one of these days we will have to have some pharo specific tools.
There will be nobody that maintains them. There will be nobody that takes responsibility and that writes and runs tests. You can see that with Davids browser, it is dead. You can see that with Services, they are dead. And many others ...
Yes but pharo is moving so slowly we will get more people taking care of packages.
But that is not the real problem. And I didn't mean Squeak (although that's a problem too, but I personally don't care). What I ment is the difference between Pharo 1.0 and Pharo 1.1.
You lost me there :)
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I spent the complete Thursday and Friday trying to get Helvetia running in Pharo 1.1, but that doesn't work because it requires some significant changes in packages like the Refactoring Rngine, the AST, Shout, eCompletion and OB that are also supposed to work on Pharo 1.0.
No there are not supposed to work in 1.0 CERTAIN frozen versions are supposed to work on 1.0 and others won't. A lot of software on mac does not run automatically on snowleopard and 10.2
Tell me if Im wrong but we should use release and version.
Adding the category dialog to OB makes it depend on 1.1, thus people cannot use it in 1.0 anymore. So the category dialog can maybe happen in a year from now. I cannot use 1.1 at the moment, I am stuck with the frozen 1.0 version.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1? I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state. Therefore, I think its a bit early to provide a public Pharo 1.1 image on the download page. This gives the false impression that also the externally maintained packages are being worked on in the 1.1 branch. Cheers, Adrian BTW: this is the same with most other software projects. E.g., I don't migrate our commercial projects to Seaside 3 at least until it is final and stable. On Dec 21, 2009, at 10:35 , Stéphane Ducasse wrote:
Adrian
lukas was frustrated because he could not have the last version of the tools like RB, helvetia working in 1.1 and 1.0 I think that this is not something that you can expect. Else we can just stop Pharo now and go to do something else.
This is why tools should work on a stable version and be marked tools for Pharo1.0 and brnaching to have tools for pharo1.1
Stef
On Dec 20, 2009, at 7:53 PM, Adrian Lienhard wrote:
Version 1.0 is the one to work with, to build and maintain tools for, etc. Unless you work on the Pharo base system there is no good reason to use 1.1 at the current time. It is unstable and it is going to change. Furthermore, nobody can expect that external packages are already flawlessly working with the moving target 1.1. At a later point when 1.1 is getting stable it makes sense to move over from 1.0 and make your packages, applications etc. work with the new version.
I don't know the details and context of the discussion that Stef posted. But I assume that it also concerns packages that are in Pharo (i.e., packages that are added to PharoCore). There we have a slightly different situation because these packages are part of the Pharo image and hence also need to follow its release regime. That is, for the release of Pharo 1.0, the added packages need to be in a stable state. The versions of the packages used in Pharo should not add new features since post release 1.0 there should only be few updates for critical fixes.
Adrian
On Dec 20, 2009, at 19:16 , Hernán Morales Durand wrote:
Hi, can you clarify what is a frozen 1.0 and which is the stable Pharo image to use as a base system to develop tools? (I cannot mantain my packages for both 1.0 and 1.1, it's a lot of work) Thanks
Hernán
2009/12/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I sent that to the list because this is really important.
one of these days we will have to have some pharo specific tools.
There will be nobody that maintains them. There will be nobody that takes responsibility and that writes and runs tests. You can see that with Davids browser, it is dead. You can see that with Services, they are dead. And many others ...
Yes but pharo is moving so slowly we will get more people taking care of packages.
But that is not the real problem. And I didn't mean Squeak (although that's a problem too, but I personally don't care). What I ment is the difference between Pharo 1.0 and Pharo 1.1.
You lost me there :)
These two versions are killing any progress on the tool front and makes any maintainer of external packages a lot of pain.
Why why don't you freeze a version for pharo1.0 Else we can just stop now. because this will be the same with pharo1.1 and 1.2 and 1.0
I spent the complete Thursday and Friday trying to get Helvetia running in Pharo 1.1, but that doesn't work because it requires some significant changes in packages like the Refactoring Rngine, the AST, Shout, eCompletion and OB that are also supposed to work on Pharo 1.0.
No there are not supposed to work in 1.0 CERTAIN frozen versions are supposed to work on 1.0 and others won't. A lot of software on mac does not run automatically on snowleopard and 10.2
Tell me if Im wrong but we should use release and version.
Adding the category dialog to OB makes it depend on 1.1, thus people cannot use it in 1.0 anymore. So the category dialog can maybe happen in a year from now. I cannot use 1.1 at the moment, I am stuck with the frozen 1.0 version.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1?
The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot.
I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state.
I do not complain, I completely agree with the Pharo development process. It is great what you are doing. I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
sure no problem. Lukas. I sent the mail because this is an important point. I think that we should also understand what is a good amount of time between two releases. On Dec 21, 2009, at 12:20 PM, Lukas Renggli wrote:
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1?
The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot.
I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state.
I do not complain, I completely agree with the Pharo development process. It is great what you are doing.
I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As already said several times. For me, we have to: 1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes. 2) Tag the 1.1 as UNSTABLE. 3) Remove 1.1 dev link from website and even do not create dev images using 1.1 for the moment. Peope should use 1.0 for their development. (this was not my idea, adrian i think). Cheers, Mariano On Mon, Dec 21, 2009 at 5:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
sure no problem. Lukas. I sent the mail because this is an important point. I think that we should also understand what is a good amount of time between two releases.
On Dec 21, 2009, at 12:20 PM, Lukas Renggli wrote:
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1?
The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot.
I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state.
I do not complain, I completely agree with the Pharo development process. It is great what you are doing.
I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
But having a dev image with unstable is nice because like that we can test it too :) I think that 1.1 should be renamed unstable and everything is solved. I misunderstood what lukas wanted to tell me: in essence the problem was not really the tools but the fact that maintaining two versions was too much. Stef
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
2) Tag the 1.1 as UNSTABLE.
3) Remove 1.1 dev link from website and even do not create dev images using 1.1 for the moment. Peope should use 1.0 for their development. (this was not my idea, adrian i think).
Cheers,
Mariano
On Mon, Dec 21, 2009 at 5:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: sure no problem. Lukas. I sent the mail because this is an important point. I think that we should also understand what is a good amount of time between two releases.
On Dec 21, 2009, at 12:20 PM, Lukas Renggli wrote:
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1?
The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot.
I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state.
I do not complain, I completely agree with the Pharo development process. It is great what you are doing.
I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, it seems renaming would already help a lot. I think it is ok to have the links to 1.1 dev images on the web page but it should be made clear what these images are supposed to serve for. Adrian On Dec 21, 2009, at 20:07 , Stéphane Ducasse wrote:
But having a dev image with unstable is nice because like that we can test it too :) I think that 1.1 should be renamed unstable and everything is solved. I misunderstood what lukas wanted to tell me: in essence the problem was not really the tools but the fact that maintaining two versions was too much.
Stef
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
2) Tag the 1.1 as UNSTABLE.
3) Remove 1.1 dev link from website and even do not create dev images using 1.1 for the moment. Peope should use 1.0 for their development. (this was not my idea, adrian i think).
Cheers,
Mariano
On Mon, Dec 21, 2009 at 5:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: sure no problem. Lukas. I sent the mail because this is an important point. I think that we should also understand what is a good amount of time between two releases.
On Dec 21, 2009, at 12:20 PM, Lukas Renggli wrote:
Lukas, is there a particular reason why you want/need your stuff to work also with 1.1?
The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot.
I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state.
I do not complain, I completely agree with the Pharo development process. It is great what you are doing.
I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
What is the suggested workflow for those of us who want to work off the stable version, and feedback where we find outstanding issues? I would expect to try out the offending code in a 'patched up to date' version of 1.0, to see if it is reproducable there, in which case a search of open bug reports, and possibly a new bug report, would be in order. Is there an easy way to maintain such an up to date version 1.0, with harvested bug fixes? ...Stan -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Dec 21, 2009 at 9:48 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
What is the suggested workflow for those of us who want to work off the stable version, and feedback where we find outstanding issues? I would expect to try out the offending code in a 'patched up to date' version of 1.0, to see if it is reproducable there, in which case a search of open bug reports, and possibly a new bug report, would be in order. Is there an easy way to maintain such an up to date version 1.0, with harvested bug fixes?
In my opinion, it is easy. If you are a Pharo developer you might want to use 1.1 and code there. If you are just a "user" of pharo, use the 1.0. If there are bugs, just report them following this: http://www.pharo-project.org/community/issue-tracking And then we see. If the bug is a "1.0 issue" we will try to fix it and integrated. Maybe it is 1.1. But it doesn't care. You should use 1.0 for your applications and report anything you want (issue, feedback, whatever) regardless 1.1 (do as if 1.1 doesn't exist). Cheers Mariano
...Stan -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
On Mon, Dec 21, 2009 at 9:48 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
What is the suggested workflow for those of us who want to work off the stable version, and feedback where we find outstanding issues? I would expect to try out the offending code in a 'patched up to date' version of 1.0, to see if it is reproducable there, in which case a search of open bug reports, and possibly a new bug report, would be in order. Is there an easy way to maintain such an up to date version 1.0, with harvested bug fixes?
In my opinion, it is easy. If you are a Pharo developer you might want to use 1.1 and code there. If you are just a "user" of pharo, use the 1.0. If there are bugs, just report them following this: http://www.pharo-project.org/community/issue-tracking
And then we see. If the bug is a "1.0 issue" we will try to fix it and integrated. Maybe it is 1.1. But it doesn't care. You should use 1.0 for your applications and report anything you want (issue, feedback, whatever) regardless 1.1 (do as if 1.1 doesn't exist).
Cheers
Mariano
...Stan
Hi Mariano, I suppose my question was mainly about how to keep that 1.0 version up with its current fixes. Is it a question of watching out for a new release on the downloads page. It would be preferable to pick up all updates (semi)automatically, in which case you know that a bug you hit is still a bug. I know I have seen bugs such as the one I just logged, but felt they were likely already in the works, or caused by something I'd done. If I can easily keep an image as the 'gold standard' of where a patched up to date image should be, I'm more likely to decide something really is a bug and log it. Cheeers, ...Stan -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Dec 21, 2009 at 11:00 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
On Mon, Dec 21, 2009 at 9:48 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
As already said several times. For me, we have to:
1) Put ALL our effort and or priority to release the 1.0 stable. This means, try to fix the 1.0 opened fixes.
What is the suggested workflow for those of us who want to work off the stable version, and feedback where we find outstanding issues? I would expect to try out the offending code in a 'patched up to date' version of 1.0, to see if it is reproducable there, in which case a search of open bug reports, and possibly a new bug report, would be in order. Is there an easy way to maintain such an up to date version 1.0, with harvested bug
fixes?
In my opinion, it is easy. If you are a Pharo developer you might want to use 1.1 and code there. If you are just a "user" of pharo, use the 1.0. If there are bugs, just report them following this: http://www.pharo-project.org/community/issue-tracking
And then we see. If the bug is a "1.0 issue" we will try to fix it and integrated. Maybe it is 1.1. But it doesn't care. You should use 1.0 for your applications and report anything you want (issue, feedback, whatever) regardless 1.1 (do as if 1.1 doesn't exist).
Cheers
Mariano
...Stan
Hi Mariano, I suppose my question was mainly about how to keep that 1.0 version up with its current fixes. Is it a question of watching out for a new release on the downloads page.
It would be preferable to pick up all updates (semi)automatically, in which case you know that a bug you hit is still a bug.
I know I have seen bugs such as the one I just logged, but felt they were likely already in the works, or caused by something I'd done. If I can easily keep an image as the 'gold standard' of where a patched up to date image should be, I'm more likely to decide something really is a bug and log it.
Stan, I am afraid I am not understanding you perfectly. Sorry if that's the case. The question is "how to have your image 1.0 updated up to date?" There are two things: 1) All the issues/fixes for EXTERNAL packages, will be comited in external repositories. Once a month, more or less, a new Pharo (dev and web) image is generated. That image is build with the latests version of the external packages (and the latest PharoCore image), thus it should contain the fixes (if there were). 2) All the issues/fixes that are INTERNAL to Pharo (pharo core) will be release us a number (ej 10599) and will be put in the "update stream". This mean you will be able to do mouse click -> "System" -> "software update" and get that latest version. But I am not sure about this as I remember a change Damien wanted to do so that the "software update" also updates the external packages (not only core). Do you know which is the state damien? I hope I don't confuse you even more hahaha. Kind regards, Mariano Cheeers, ...Stan
-- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stan The process we have in mind is that if the bug is **really** important then it will be fixed in 1.1 and 1.0. We did that in the past for Squeak 3.9. Now normal improvements changes.... will not be retro-ported because we simply cannot. And you are right to report a bug it is important in the future that people check if the bug is already fixed in the current unstable else we will not be able to make process and we will spend our time testing. Mariano we should update the web page how to submit a bug...
Hi Mariano, I suppose my question was mainly about how to keep that 1.0 version up with its current fixes. Is it a question of watching out for a new release on the downloads page.
It would be preferable to pick up all updates (semi)automatically, in which case you know that a bug you hit is still a bug.
I know I have seen bugs such as the one I just logged, but felt they were likely already in the works, or caused by something I'd done. If I can easily keep an image as the 'gold standard' of where a patched up to date image should be, I'm more likely to decide something really is a bug and log it.
Cheeers, ...Stan
-- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
The process we have in mind is that if the bug is **really** important then it will be fixed in 1.1 and 1.0. We did that in the past for Squeak 3.9. Now normal improvements changes.... will not be retro-ported because we simply cannot. And you are right to report a bug it is important in the future that people check if the bug is already fixed in the current unstable else we will not be able to make process and we will spend our time testing.
It sounds like the periodic 1.0 releases need to include a known problems file, which would include all bugs fixed in 1.1 alpha but not planned to be retrofitted. And it's probably important to make clear that, if in doubt, we should log a bug and risk it being a duplicate. Because the people with a genius for finding bugs are new users, and they may not be able to tell whether or not it's the same bug. -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Yes in an ideal world. Now either we can script the bugreport to generate that list automatically or we will not have the resources to do it. Then I do not imagine somebody patient enough to read a log full of bug descriptions. :) But may be I'm just too lazy. Stef On Dec 22, 2009, at 10:24 AM, Stan Shepherd wrote:
Stéphane Ducasse wrote:
The process we have in mind is that if the bug is **really** important then it will be fixed in 1.1 and 1.0. We did that in the past for Squeak 3.9. Now normal improvements changes.... will not be retro-ported because we simply cannot. And you are right to report a bug it is important in the future that people check if the bug is already fixed in the current unstable else we will not be able to make process and we will spend our time testing.
It sounds like the periodic 1.0 releases need to include a known problems file, which would include all bugs fixed in 1.1 alpha but not planned to be retrofitted. And it's probably important to make clear that, if in doubt, we should log a bug and risk it being a duplicate. Because the people with a genius for finding bugs are new users, and they may not be able to tell whether or not it's the same bug.
-- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Yes in an ideal world. Now either we can script the bugreport to generate that list automatically or we will not have the resources to do it.
Then I do not imagine somebody patient enough to read a log full of bug descriptions. :) But may be I'm just too lazy.
Stef On Dec 22, 2009, at 10:24 AM, Stan Shepherd wrote:
Stéphane Ducasse wrote:
The process we have in mind is that if the bug is **really** important then it will be fixed in 1.1 and 1.0. We did that in the past for Squeak 3.9. Now normal improvements changes.... will not be retro-ported because we simply cannot. And you are right to report a bug it is important in the future that people check if the bug is already fixed in the current unstable else we will not be able to make process and we will spend our time testing.
It sounds like the periodic 1.0 releases need to include a known problems file, which would include all bugs fixed in 1.1 alpha but not planned to be retrofitted. And it's probably important to make clear that, if in doubt, we should log a bug and risk it being a duplicate. Because the people with a genius for finding bugs are new users, and they may not be able to tell whether or not it's the same bug.
-- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________
Is it possible to add a new status in Google Code, of Closed-KPF-1.0? Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means fixed only in 1.1alpha. Making the KPF list becomes trivial. And it also captures the knowledge of whether the issue applied to 1.0 at the time of closing, rather than someone have to puzzle over it when making a release. ...Stan -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Right now we have milestone1.0 and milestone1.1 for the fixes that are integrated in both But indeed we could have a specific tags. Stef
Is it possible to add a new status in Google Code, of Closed-KPF-1.0? Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means fixed only in 1.1alpha. Making the KPF list becomes trivial. And it also captures the knowledge of whether the issue applied to 1.0 at the time of closing, rather than someone have to puzzle over it when making a release. ...Stan
-- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Right now we have milestone1.0 and milestone1.1 for the fixes that are integrated in both But indeed we could have a specific tags.
Stef
Is it possible to add a new status in Google Code, of Closed-KPF-1.0? Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means fixed only in 1.1alpha. Making the KPF list becomes trivial. And it also captures the knowledge of whether the issue applied to 1.0 at the time of closing, rather than someone have to puzzle over it when making a release. ...Stan
So would: http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect+... http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect+... Be the KPF IFF the type and status and milestone fields were maintained? -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
So would: http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect+...
Be the KPF IFF the type and status and milestone fields were maintained?
I'm not sure because what I saw was more 1.1 updates. Normally we have milestone 1.0 for 1.0 milestone 1.1 for 1.1 and when an issue should be back ported it gets the two tags.
participants (6)
-
Adrian Lienhard -
Hernán Morales Durand -
Lukas Renggli -
Mariano Martinez Peck -
Stan Shepherd -
Stéphane Ducasse