Notes about Pharo 6 release and new process for Pharo 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Notes about Pharo 6 release and new process for Pharo 7

EstebanLM
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


Reply | Threaded
Open this post in threaded view
|

Re: Notes about Pharo 6 release and new process for Pharo 7

EstebanLM
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 <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Notes about Pharo 6 release and new process for Pharo 7

Thierry Goubier


2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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 <[hidden email]> 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
>



Reply | Threaded
Open this post in threaded view
|

Re: Notes about Pharo 6 release and new process for Pharo 7

EstebanLM

On 25 Oct 2016, at 14:27, Thierry Goubier <[hidden email]> wrote:



2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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 <[hidden email]> 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
>




Reply | Threaded
Open this post in threaded view
|

Re: Notes about Pharo 6 release and new process for Pharo 7

kilon.alios
In reply to this post by EstebanLM


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)



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.  
Reply | Threaded
Open this post in threaded view
|

Re: Notes about Pharo 6 release and new process for Pharo 7

EstebanLM

On 25 Oct 2016, at 15:01, Dimitris Chloupis <[hidden email]> 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)



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.