Pharo7 - git - branches - platforms - baseline ?

Hi,

Pharo 7 is coming closer to a release so it is good that Seaside loads well into the latest Pharo 7 RC, especially the #pharo7 branch.

Although the differences between the #master and #pharo7 branch are small (just 2 methods), the question is how to integrate those fixes (as they are specific to pharo 7). (See the gaps in the CI build matrix).

When I look at BaselineOfSeaside3 I get really confused. This is so complex, so verbose that I feel intimidated to propose any changes. Even though Seaside is complex and supports different platforms and different versions of those platforms, we should be able to do much better.

What are the guidelines/ideas/plans here ? What is the strategy ?

IMHO, a baseline should first and foremost clearly describe an ideal situation in #common, and only then define - ideally small - exceptions for different platforms/versions. It should be possible to first see and understand the base structure.

Groups, sub components and dependencies should be clear.

It might also help to cut some support for very old versions and or platforms that do not yet support git based loading.

Or should each branch hold its own, much cleaner baseline ? And will we then keep on maintaining different branches ?

Wasn't it also the goal to put platform differences in Grease as much as possible ?

Sven



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Le 04/12/2018 à 17:13, Sven Van Caekenberghe a écrit : Hi,

I am currently cleaning a little the baseline and packages to remove
everything related to Pharo < 4. One fix is already integrated. 3 other
are waiting review and when they will be integrated I'll check if I can
further clean it. (I think I already see one or two things I can clean
but I don't want to do too many PR that will end up in conflict)

As you can see here for example:

https://github.com/SeasideSt/Seaside/pull/1056/files

It reduce quite a lot the complexity of some parts.

Another example: https://github.com/SeasideSt/Seaside/pull/1054/files

> Sven
>
>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>


--
Cyril Ferlicot
https://ferlicot.fr


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi Sven,

> On 4 Dec 2018, at 17:13, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Pharo 7 is coming closer to a release so it is good that Seaside loads well into the latest Pharo 7 RC, especially the #pharo7 branch.


> Although the differences between the #master and #pharo7 branch are small (just 2 methods), the question is how to integrate those fixes (as they are specific to pharo 7). (See the gaps in the CI build matrix).

I should delete the pharo7 branch, because all those changes were merged into develop, which is really pharo7 ready. The pharo7 branch is not.
It was only created to make the changes specific to pharo7, but all changes have been merged into develop and more fixes have been made.

Which gaps do you mean in the build matrix? I don’t understand.
e.g. https://travis-ci.org/SeasideSt/Seaside/builds/459433036

> When I look at BaselineOfSeaside3 I get really confused. This is so complex, so verbose that I feel intimidated to propose any changes. Even though Seaside is complex and supports different platforms and different versions of those platforms, we should be able to do much better.
> What are the guidelines/ideas/plans here ? What is the strategy ?

The baseline is split into conceptual parts (comet, rest, core, …)
I think the only one that grew out to a beast is the Pharo parts.
And that part is being slimmed down (thank you Cyril) because old Pharo versions are being thrown out.

I think it’s underestimated how complex a package configuration can get when you have different platforms to support.
Sure, it’s possible to come in and say everything should be easier, but

The only thing that, in hindsight would have been easier, is to not try to reuse packages across different Pharo versions but rather create complete copies. This is the approach we have taken for Grease. Take a look there to see what I mean.

> IMHO, a baseline should first and foremost clearly describe an ideal situation in #common, and only then define - ideally small - exceptions for different platforms/versions. It should be possible to first see and understand the base structure.

The differences between the platforms are not small and are hard to capture by Grease everywhere.
In most cases, it is necessary to put platform-specific parts of Seaside into platform-specific packages.

> Groups, sub components and dependencies should be clear.
>
> It might also help to cut some support for very old versions and or platforms that do not yet support git based loading.
>
> Or should each branch hold its own, much cleaner baseline ? And will we then keep on maintaining different branches ?

We specifically merged the entire Gemstone ‘branch’ of Seaside of with the main repository because it was maintenance hell.
Hence, I don’t like splitting Seaside in different platform branches. In fact, I’m certain it will fail to be maintained.
We merged Gemstone back in (at ESUG in Brescia actually) and the maintenance of the entire Seaside code base has been simplified for both Pharo and Gemstone, but there is still room for improvement, obviously.

Having the travis builds for all platforms is definitely a winner too.

> Wasn't it also the goal to put platform differences in Grease as much as possible ?


Yes it is, and we are still moving things up to Grease, but many platform differences also do not make sense to put in Grease.

cheers
Johan
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev