[ANN] Pharo 8.0 development started

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

[ANN] Pharo 8.0 development started

EstebanLM
Hello all,

We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :)

So you now can start making Pull Requests against Pharo8.0 branch :)

Esteban
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Alistair Grant
Hi Esteban,

Can I get in an early request for a new VM for Pharo 8?

Since the normal process is to ensure the VM is at least 2 weeks old
it doesn't require any action now, and of course it can wait until
Pharo 7 is released.

- Linux 64 bit:
http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201812211409-1015842.zip
- Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-1015842.dmg
- Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d4d6.zip

Thanks!

Alistair

On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <[hidden email]> wrote:
>
> Hello all,
>
> We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :)
>
> So you now can start making Pull Requests against Pharo8.0 branch :)
>
> Esteban

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

EstebanLM
Hi Alistair,

I’m waiting to fix some issues in current VM build (new freetype lib, ensure Athens will work on 64bit windows) and I was going to declare that “final vm for Pharo7”.
Then this final VM for P7 will be the first for P8 :)

Esteban

> On 27 Dec 2018, at 15:11, Alistair Grant <[hidden email]> wrote:
>
> Hi Esteban,
>
> Can I get in an early request for a new VM for Pharo 8?
>
> Since the normal process is to ensure the VM is at least 2 weeks old
> it doesn't require any action now, and of course it can wait until
> Pharo 7 is released.
>
> - Linux 64 bit:
> http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201812211409-1015842.zip
> - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-1015842.dmg
> - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d4d6.zip
>
> Thanks!
>
> Alistair
>
> On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <[hidden email]> wrote:
>>
>> Hello all,
>>
>> We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :)
>>
>> So you now can start making Pull Requests against Pharo8.0 branch :)
>>
>> Esteban
>


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Alistair Grant
Hi Esteban,

On Thu, 27 Dec 2018 at 15:52, Esteban Lorenzano <[hidden email]> wrote:
>
> Hi Alistair,
>
> I’m waiting to fix some issues in current VM build (new freetype lib, ensure Athens will work on 64bit windows) and I was going to declare that “final vm for Pharo7”.
> Then this final VM for P7 will be the first for P8 :)

Great, that will include the updates that I'm waiting for:  updates to
FileAttributesPlugin. I'll then be able to (finally) submit the patch
for the image code.

Thanks!
Alistair



> Esteban
>
> > On 27 Dec 2018, at 15:11, Alistair Grant <[hidden email]> wrote:
> >
> > Hi Esteban,
> >
> > Can I get in an early request for a new VM for Pharo 8?
> >
> > Since the normal process is to ensure the VM is at least 2 weeks old
> > it doesn't require any action now, and of course it can wait until
> > Pharo 7 is released.
> >
> > - Linux 64 bit:
> > http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201812211409-1015842.zip
> > - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-1015842.dmg
> > - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d4d6.zip
> >
> > Thanks!
> >
> > Alistair
> >
> > On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <[hidden email]> wrote:
> >>
> >> Hello all,
> >>
> >> We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :)
> >>
> >> So you now can start making Pull Requests against Pharo8.0 branch :)
> >>
> >> Esteban
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Torsten Bergmann
In reply to this post by EstebanLM
Hi Esteban,

you know I'm neither shy on contributing nor doing any work for Pharo but personally I think we open Pharo 8 too early and should better focus our efforts more
on finalizing P7 (see below) instead of opening the next construction site.

Things were already shaky and sometimes painful with P7 - nonetheless I managed to get 762 commits into it. Often simple or boring PR's just to get packages, classes, methods
in shape and clean up. Funny enough I can now say I'm on top of https://github.com/pharo-project/pharo/graphs/contributors ;)

I had a hard time finding out how things work in the new git/pharo/externally managed projects combination - sometimes also with broken or unfinished tools. A newly opened
P8 so early adds even more on top...

Several things directly came into my mind:

 1. http://bugs.pharo.org now points to nirvana now

 2. http://ci.pharo.org  point to nirvana now as well

 3. It's unclear to me what will happen to the bugtracker mailinglist archive. Currently I often use it to stay informed about our changes.
    Will it stop in december?

    https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/

 4. The CI for Pharo 7 was not green in most of the latest commits ... and situation for Pharo 8 is not even better now: RED all over on

    https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

 5. We still have dirty packages in Pharo 7 - the last remaining issue here
    https://github.com/pharo-ide/Calypso/issues/386
    is still not solved and there was no reaction on Discord after reminding it twice.

 6. Calypso still has hard issue in Pharo 7 - most of them already fixed in Calypso project.

    But integration of the new Calypso version is still pending  https://github.com/pharo-project/pharo/pull/2115 

    Nonetheless we already switch to P8?

 7. A change done lately (around 17.12.) was resetting the build numbers - so for whatever strange reason we started with 1 again
    althoug we were already at Build 1416 for Pharo 7 with all the integrations.
     
    https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

    This build number issue was not yet fixed although this is a serious issue to compare image buils or be able to download using Launcher.

    Nonetheless we already switch to P8?
 
 8. Lately we switched the branches from "development" to "Pharo7.0" and now also "Pharo8.0". This was also just announced - without any discussion
    in advance forcing people to resetup their tools and local repos.

    This change is still not event reflected in the contribution guideline ... but we already switch to Pharo 8

 9. We still have lots of important and must-fix cases for Pharo 7
    https://pharo.fogbugz.com/f/filters/1412/7-0-All

10. There was nothing said about backporting strategy between the new P8 and P7 now...


To me it would already help a little bit to clarify the above raised points and get a more detailed info about the next P7 steps towards the release.

Independent from that I fear we constantly decouple more and more people with too many process and contribution scheme changes at once. From the discussions
on Discord I already see many people struggle - and often not only the beginners.

Bye
T.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Torsten Bergmann
and

  11. There is no https://get.pharo.org/80 yet ...

Bye
T.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Pharo Smalltalk Developers mailing list
In reply to this post by Torsten Bergmann
Hi Torsten,

I think most of your concerns are due a miss-explanation about what it means opening P8 branch.
It does not means we are releasing P7 or stopping to work on it. It means people can now do pull requests that would not be accepted for Pharo 7.0 in a different branch.

Pharo 7.0 is not done and we are not switching to Pharo 8.0 now. This is just to allow some changes to be integrated without restricting people contributions just because P7 release is stuck because other problems.


On 27 Dec 2018, at 21:06, Torsten Bergmann <[hidden email]> wrote:

Hi Esteban,

you know I'm neither shy on contributing nor doing any work for Pharo but personally I think we open Pharo 8 too early and should better focus our efforts more
on finalizing P7 (see below) instead of opening the next construction site.

Things were already shaky and sometimes painful with P7 - nonetheless I managed to get 762 commits into it. Often simple or boring PR's just to get packages, classes, methods
in shape and clean up. Funny enough I can now say I'm on top of https://github.com/pharo-project/pharo/graphs/contributors ;)

I had a hard time finding out how things work in the new git/pharo/externally managed projects combination - sometimes also with broken or unfinished tools. A newly opened
P8 so early adds even more on top...

Several things directly came into my mind:

1. http://bugs.pharo.org now points to nirvana now

This is like that since a lot (not to say it shouldn’t be fixed, but to explain that is no blocker).
That address needs to be redirected or decommissioned.


2. http://ci.pharo.org  point to nirvana now as well

Same. 
I think this is due some migration in INRIA servers, 
In any case, this is orthogonal.


3. It's unclear to me what will happen to the bugtracker mailinglist archive. Currently I often use it to stay informed about our changes.
   Will it stop in december?

   https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/

We should redirect pharo issues to them.


4. The CI for Pharo 7 was not green in most of the latest commits ... and situation for Pharo 8 is not even better now: RED all over on

   <a href="https://ci.inria.fr/pharo-ci-jenkins2/job/Test pending pull request and branch Pipeline/" class="">https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

Is a problem in our CI, not in the image it self.
I’m not happy with it, but again this is orthogonal.

5. We still have dirty packages in Pharo 7 - the last remaining issue here
   https://github.com/pharo-ide/Calypso/issues/386
   is still not solved and there was no reaction on Discord after reminding it twice.

This needs to be solved, yes.
There was not reaction because mostly I was not around ;)


6. Calypso still has hard issue in Pharo 7 - most of them already fixed in Calypso project.

   But integration of the new Calypso version is still pending  https://github.com/pharo-project/pharo/pull/2115

Yes, we know :)


   Nonetheless we already switch to P8?

We didn’t switch to P8. We open P8 dev branch.


7. A change done lately (around 17.12.) was resetting the build numbers - so for whatever strange reason we started with 1 again
   althoug we were already at Build 1416 for Pharo 7 with all the integrations.

   https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

   This build number issue was not yet fixed although this is a serious issue to compare image buils or be able to download using Launcher.

Build numbers are created /per branch/, not by job. This is a problem indeed but we do not have a solution for it. 
Real solution will be to change launcher to not consider build number (but take build date, we don’t know)


   Nonetheless we already switch to P8?

Again, we didn’t switch, we just opened. 


8. Lately we switched the branches from "development" to "Pharo7.0" and now also "Pharo8.0". This was also just announced - without any discussion
   in advance forcing people to resetup their tools and local repos.

   This change is still not event reflected in the contribution guideline ... but we already switch to Pharo 8

The full purpose of the change was to be able to have two (or more) branches opened simultaneously. 
And yes, there will be a Pharo8.0 (and eventually a Pharo9.0), etc. branches… 


9. We still have lots of important and must-fix cases for Pharo 7
   https://pharo.fogbugz.com/f/filters/1412/7-0-All

I know. 
I’m almost the only one working on them.


10. There was nothing said about backporting strategy between the new P8 and P7 now…

It was said. 
Backport will happen by doing pull requests to the different, active, branch. 
Frontport (from P7 to P8) will be made in the same way, in regular basis.



To me it would already help a little bit to clarify the above raised points and get a more detailed info about the next P7 steps towards the release.


We still not release P7!.
 To do that, we need several things to align before: 

- 64bit windows vm
- new freetype2 version (2.9.1) in all platforms.
- Calypso glitches
- Some other cleanings (I do not remember exactly right now, I’m on holidays until 7/01 :P)


Independent from that I fear we constantly decouple more and more people with too many process and contribution scheme changes at once. From the discussions
on Discord I already see many people struggle - and often not only the beginners.

People struggle always. 
We try to help, and to simplify. 
Some times with better results than others.
But there is no such thing as an “effortless contribution”, it was not like that before and it is not like that now. 

But I will write another mail about this later.

Cheers!
Esteban



Bye
T.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Pharo Smalltalk Developers mailing list
In reply to this post by Torsten Bergmann


> On 27 Dec 2018, at 21:13, Torsten Bergmann <[hidden email]> wrote:
>
> and
>
>  11. There is no https://get.pharo.org/80 yet …

Because there is no release!
As I said before, most of yours concerns are because I failed to explain correctly the purpose of a Pharo 8.0 branch opening.

Esteban

>
> Bye
> T.
>


Reply | Threaded
Open this post in threaded view
|

About contribution process, people participation and communication (WAS: Re: [ANN] Pharo 8.0 development started)

Pharo Smalltalk Developers mailing list
In reply to this post by Torsten Bergmann
Hi Torsten (again),

What I see in your mails, and what I think is most important to discuss, is a subjacent critique about the way we communicate our changes. And maybe more than that: a disagreement about the general direction of changes in process.

While I recognise we can communicate better (and we take any criticism in that sense as a remark of our need to improve), is not fair to say that we did not announce what we were doing:

- it is told and very discussed the fact that we were going to a git based process and supported by github. This *was* discussed and announced. And we worked a lot last year to make it possible (and is the main reason why we delayed P7 release).
- We announced that we were moving our issue tracker to GitHub at least 6-8 months before (in fact we were ready to do it in that moment but we delayed it “for Pharo8” to avoid transition problems.
- We announced that we wanted to have at least two branches opened at same time, and to make that possible.

Now, while the general direction was explained, I think I failed to communicate several things.
For what I can think at this moment (for sure there are a lot more):  

- I failed to communicate that opening Pharo 8.0 branch didn’t mean closing Pharo 7.0 development, just to allow people doing big changes to merge them.
- I failed to communicate correctly that having a release candidate (rc1) meant “code freeze” (and then forbidding new changes except bug fixing).

New process is different than old process.
And we had transition problems (and we still have some).
But new process is a lot better than old one. Is faster, shorter and it allows us to have different branches alive :)

But well, let’s focus in the positive: We are improving in an area that is always hard, which is process.
I’m deeply sorry if someone felt alienated in the process of changing process (I know for windows users it was a problem until we introduced Tonel, for example).
And specially, we are willing to improve.
So, I’d like to see your suggestions (and any one else with ideas) on how can we improve both process and communication.

Esteban
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Pharo 8.0 development started

Sean P. DeNigris
Administrator
In reply to this post by Pharo Smalltalk Developers mailing list
Pharo Smalltalk Developers mailing list wrote
> I’m on holidays until 7/01 :P

Esteban, thank you for all your incredible work on all these simultaneous
big, hard problems! Now stop sending mails and go enjoy your holiday ;-)



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: About contribution process, people participation and communication (WAS: Re: [ANN] Pharo 8.0 development started)

Ben Coman
In reply to this post by Pharo Smalltalk Developers mailing list
On Sun, 30 Dec 2018 at 23:28, Esteban Lorenzano via Pharo-dev <[hidden email]> wrote:

Now, while the general direction was explained, I think I failed to communicate several things.
For what I can think at this moment (for sure there are a lot more): 

- I failed to communicate that opening Pharo 8.0 branch didn’t mean closing Pharo 7.0 development, just to allow people doing big changes to merge them.
- I failed to communicate correctly that having a release candidate (rc1) meant “code freeze” (and then forbidding new changes except bug fixing).

Thanks for acknowledging this Esteban. In spite of the communication issue, the point I'd make in support of this arrangement is that historically 
we've done poorly with code-freezes, or even the lesser strength feature-freezes leading up to a release.  A code freeze can be discouraging 
when integration of new features are delayed and can weaken such the code freeze. Opening the next-version-dev branch when the current-version 
freezes for release-candidate seems to facilitate pre-release stability - though the risk though of mind-share drifting to the next-version-dev branch needs to be managed.

cheers -ben