> On 25 Oct 2016, at 14:27, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > > > 2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@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 <esteba...@gmail.com > > <mailto:esteba...@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 > > > > >
