[Pharo-users] How to contribute to Calypso when it relies on pharo-core editors?

Guillermo Polito guillermopolito at gmail.com
Wed Jun 20 08:05:48 EDT 2018


On Wed, Jun 20, 2018 at 1:47 PM Ben Coman <btc at openinworld.com> wrote:

>
>
> On 20 June 2018 at 15:38, Guillermo Polito <guillermopolito at gmail.com>
> wrote:
>
>> Hi Tim,
>>
>> Yes, there you're experiencing the limits of our current process. We were
>> studying the usage of git subtrees/submodules/subrepos but none of them
>> seem a satisfying solution for what would give us a smooth contribution
>> process.
>>
>> Now, we can enhance a bit the current status by adding calypso in the
>> list of iceberg projects. I agree with this. Actually putting Pharo and
>> Iceberg itself there is something we started to do slowly. There was this
>> feeling that people would complain "agh but I only want to see my projects
>> not the system ones". What I believe is that we are used to see and change
>> all packages in the system, that's in our "blood" as pharoers. So seeing
>> all loaded projects may confuse a bit newcomers but empower experts too...
>>
>
> Just random musing...
> It must be common that projects depend on several repos, so perhaps
> Iceberg could present repos in a two level tree.
> The first level is a "project" of which "Pharo" would be one, with second
> level holding Iceberg and Calypso.
> This could be condensed by default so that adding extra default Pharo
> system repos doesn't clutter much.
> If this could somehow tie in with tracking the repos loaded by Baselines,
> that would be super cool. i.e. Baseline=Project.
>

We are adding the idea of projects to iceberg in the release 1.2 ;)
The idea so far is that an iceberg project will remember at first what is
the code subdirectory (so people don't have to type it all over!).
But this opens the idea to have composite projects in the future.


> Then we don't use the existing subtree/submodule/subrepos, just
> baselines.
> After all, those three standard options all started out as separate
> scripts tacked onto git - its flexible like that.
>

Well, yes and no. That does not quite solve the issue.
Reifying projects add some flexibility, but it does not handle inter
git-repository dependencies.
The case is the following:

- pharo is stored in pharo-project/pharo.git
- calypso is stored in pharo-contributions/calypso.git

Regardless how you show them in the UI, let's suppose now that you want to
do a change that involves both.

Scenario 1) That is, you have:

pharo v1
calypso v1

And you want to

pharo v2
calypso v2

If the change in either is dependent on the other, and/or for example
breaks backwards compatibility, this means there is an implicit dependency
between pharo and calypso.

But, next time you build pharo, you load v2, and then you find yourself
with:

pharo v2
calypso v1

And everything breaks :)

Scenario 2) This could be solved by first doing a calypso release marking
v2, and once that release is finished and public, doing a new pharo v2
release with the proper calypso version. But now, all this "administrative
cost" means that there is a time gap between the release of calypso v2 and
the release of pharo v2.
In this moment, if you just load bleeding edge version, you may have a
build with:

pharo v1
calypso v2

Which may also break if proper care with backwards compatibility was not
taken!

Nowadays, both calypso and Iceberg are managed like in *scenario 2*.
This adds some some safety and order at the cost of bureaucracy (partial
releases, care for backwards compatibility).

Generally speaking, I'd like in the future a solution where there is a good
tradeoff between safety and flexibility/speed.

Guille
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180620/fc74be16/attachment-0001.html>


More information about the Pharo-users mailing list