Notes about Pharo 6 release and new process for Pharo 7
Time to send this to dev list: (btw, this has to do with what we are going to talk today in TechTalk). Hi, Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today). The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly. Anyway, this is what we think: We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: - Clements changes (full blocks, SISTA bytecode set, â¦) - 64bits - Bugfixes This way we can jump to work on the new process, that we think will take some months until we have it ready. NEW PROCESS: 1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working) 2) Sources will be moved to git. Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodules⦠Anyway I would like to have different source directories (to separate kernel from maintained packages :P) 3) Changes will be managed through Pull Requests (yay!) And of course there will be a validation process (travis based)⦠- Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)⦠I mean, the build images for validation⦠of course the âintegratedâ images will be pushed allways. This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. This way, when 7.0 starts in march, we are with the new process. So that. Opinions, suggestions? Esteban
and I will paste Stefâs clarification, because it seems my text was a bit obscure :) Pharo 6.0 will be with the old process. - no bootstrap - no git - 64 bits - stabilisation But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. - with bootstrap - process based on git The idea is to have some months to get Pharo 70 alpha ready with the new process when Pharo 60 gets out (or at least to get some cycles)
On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Time to send this to dev list: (btw, this has to do with what we are going to talk today in TechTalk).
Hi,
Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today).
The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly.
Anyway, this is what we think:
We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: - Clements changes (full blocks, SISTA bytecode set, â¦) - 64bits - Bugfixes
This way we can jump to work on the new process, that we think will take some months until we have it ready.
NEW PROCESS:
1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working)
2) Sources will be moved to git. Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodules⦠Anyway I would like to have different source directories (to separate kernel from maintained packages :P)
3) Changes will be managed through Pull Requests (yay!) And of course there will be a validation process (travis based)⦠- Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)⦠I mean, the build images for validation⦠of course the âintegratedâ images will be pushed allways.
This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. This way, when 7.0 starts in march, we are with the new process.
So that.
Opinions, suggestions?
Esteban
2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
and I will paste Stefâs clarification, because it seems my text was a bit obscure :)
Pharo 6.0 will be with the old process. - no bootstrap - no git - 64 bits
So Pharo 6 will be 64 bits? Yes! Thierry
- stabilisation
But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. - with bootstrap - process based on git The idea is to have some months to get Pharo 70 alpha ready with the new process when Pharo 60 gets out (or at least to get some cycles)
On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Time to send this to dev list: (btw, this has to do with what we are going to talk today in TechTalk).
Hi,
Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today).
The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly.
Anyway, this is what we think:
We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: - Clements changes (full blocks, SISTA bytecode set, â¦) - 64bits - Bugfixes
This way we can jump to work on the new process, that we think will take some months until we have it ready.
NEW PROCESS:
1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working)
2) Sources will be moved to git. Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodules⦠Anyway I would like to have different source directories (to separate kernel from maintained packages :P)
3) Changes will be managed through Pull Requests (yay!) And of course there will be a validation process (travis based)⦠- Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)⦠I mean, the build images for validation⦠of course the âintegratedâ images will be pushed allways.
This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. This way, when 7.0 starts in march, we are with the new process.
So that.
Opinions, suggestions?
Esteban
On 25 Oct 2016, at 14:27, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: and I will paste Stefâs clarification, because it seems my text was a bit obscure :)
Pharo 6.0 will be with the old process. - no bootstrap - no git - 64 bits So Pharo 6 will be 64 bits? Pharo 6 will *have* 64bits version. We will continue having the 32bits version for some time (and some more versions), I guessâ¦
Esteban
Yes!
Thierry
- stabilisation
But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. - with bootstrap - process based on git The idea is to have some months to get Pharo 70 alpha ready with the new process when Pharo 60 gets out (or at least to get some cycles)
On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
Time to send this to dev list: (btw, this has to do with what we are going to talk today in TechTalk).
Hi,
Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today).
The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly.
Anyway, this is what we think:
We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: - Clements changes (full blocks, SISTA bytecode set, â¦) - 64bits - Bugfixes
This way we can jump to work on the new process, that we think will take some months until we have it ready.
NEW PROCESS:
1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working)
2) Sources will be moved to git. Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodules⦠Anyway I would like to have different source directories (to separate kernel from maintained packages :P)
3) Changes will be managed through Pull Requests (yay!) And of course there will be a validation process (travis based)⦠- Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)⦠I mean, the build images for validation⦠of course the âintegratedâ images will be pushed allways.
This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. This way, when 7.0 starts in march, we are with the new process.
So that.
Opinions, suggestions?
Esteban
1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working)
https://www.youtube.com/watch?v=_J6-3l3hCm0 That going to be even bigger than 64 bit, will make it easy to have Pharo distros :) I am very interested into hearing about this in the voice meeting . By the way what time is the meeting ? local time France is fine too.
On 25 Oct 2016, at 15:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working)
https://www.youtube.com/watch?v=_J6-3l3hCm0 <https://www.youtube.com/watch?v=_J6-3l3hCm0>
That going to be even bigger than 64 bit, will make it easy to have Pharo distros :)
I am very interested into hearing about this in the voice meeting . By the way what time is the meeting ? local time France is fine too.
18hs france.
participants (3)
-
Dimitris Chloupis -
Esteban Lorenzano -
Thierry Goubier