Point one

Hi

today we brainstormed and I will send a sequence of emails to discuss
what we decided
and started to do.

One of our goal is to check if we can use versionner to manage all the
configurations.
It looks possible.

The first things we started to do is
     - make sure that all the configurations of external libraries are
correctly defined.
     In particular we made sure that a version does not depend on a
stable one but on a version specific.

     - We think that Moose should not depend on baseline of external
tools, because we need real reproduceability.

     - We started to produce configurations with versionner that do not
depend on stable but on exact versions.

     - I will continue to see if we can use Versionner because it would
simplify the release.

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Steph wrote:
>     - make sure that all the configurations of external libraries are
>correctly defined.
>     In particular we made sure that a version does not depend on a
>stable one but on a version specific.

I would recommend against using detailed numbered versions
for this. That couples you to bug fix patches/updates in the external
libraries and creates a very high versioning effort.

In Seaside we use release3 release30 release31 instead of stable.
Release3 introduced a different packaging, and 31 has some interface
changes. We can now safely promote a new version to stable without
having to update all configurations using seaside.
 
This reduces the versioning effort, at some loss in reproducibility.
For that, separate snapshots are perfect.

Cheers,
  Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes, it would be great to have a configuration version for each change. But, for some reason, it is hard to have in moose. I spent quite some days trying to fix this

Alexandre

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 28/6/14 00:56, Stephan Eggermont wrote:
> Steph wrote:
>>      - make sure that all the configurations of external libraries are
>> correctly defined.
>>      In particular we made sure that a version does not depend on a
>> stable one but on a version specific.
> I would recommend against using detailed numbered versions
> for this. That couples you to bug fix patches/updates in the external
> libraries and creates a very high versioning effort.

Pressing one button to load one to release and one to commit is not that
complex.
If necessary we will build a tool that does is automatically. Releasing
a real fixed version is important.
I'm sorry stefan but we want FULL reproducibility.

We cannot sign contracts when we maintain deployed systems by just
saving images and preying.

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I agree with this recommendation ... a very good use of symbolic versions and I plan to propagate this pattern without the gemstone universe...

Why Java practices would be so wrong?
I do not even want to discuss it in fact. With a release version should be fixed.
If people do not like it, then I will create and maintain my own configurations. I have no problem with that.
In fact it would even simplify our problems.

I'm proposing solutions to avoid to fork but if necessary we will fork.
I think that we can fully manage Moose with versionner and this is not the case of Seaside because of platform specific features that
are not supported by versionner.

Stef

Dale

On Fri, Jun 27, 2014 at 3:56 PM, Stephan Eggermont <[hidden email]> wrote:

Steph wrote:
>     - make sure that all the configurations of external libraries are
>correctly defined.
>     In particular we made sure that a version does not depend on a
>stable one but on a version specific.

I would recommend against using detailed numbered versions
for this. That couples you to bug fix patches/updates in the external
libraries and creates a very high versioning effort.

In Seaside we use release3 release30 release31 instead of stable.
Release3 introduced a different packaging, and 31 has some interface
changes. We can now safely promote a new version to stable without
having to update all configurations using seaside.

This reduces the versioning effort, at some loss in reproducibility.
For that, separate snapshots are perfect.

Cheers,
  Stephan

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Yes, it would be great to have a configuration version for each change. But, for some reason, it is hard to have in moose. I spent quite some days trying to fix this
Did you try to do it with versionner? Without a tool this is a hell.
Now I think that it will work with versionner. In one click I can
release a versionned solution.
We tried with some configurations of the moose ecosystems and it look
like this is working.
So I will continue the experience to see if this is working,
snaphotcello is not a good solution (it is what is working)
but as mentioned Stefan it flattens and pollutes the configuration.

Now if people shout and I will just fork the configurations. Because
this is not acceptable that
we cannot reload one version of Moose. We could have a release process
as follows

     - develop on baseline
     - release every friday on versions

I do not see why this is not possible.

Stef

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

So far we (Guillaume, christophe and me) addressed clean the mess and
make sure that we can manage the following configuration with versionner

     XMLWriter
     XMLParser
     Pastell
     PhExample
     OrderPreserving
     BitmapCharacterSet
     HashTable
     Fame

We will probably ask christophe that versionner on release proposes the
choice to use stable or the version.

     I will continue
     with

     Units
     MooseAlgoRubric
     SmallDude
     MetaNool
     Maggrite3

Now I will probably have to fork some configurations if I cannot publish
on the repositories.

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Steph wrote:
>If necessary we will build a tool that does is automatically. Releasing
>a real fixed version is important.
>I'm sorry stefan but we want FULL reproducibility.

A snapshot is a separate concept from a configuration. Building a separate
tool to create snapshots is a good idea. A snapshot should know about
a configuration but not the other way around.

The problem we run into is that we use configuration A that depends
on version B1 of a configuration, and another configuration C that depends
on version B2. So we need to create a new configuration version of A,
even though A is not interested in C.

To make that work dependent configurations would need
to change at the sum of change rate of all the configurations they are
depending on.  As long as we don't have global flow (in the lean sense) that is
unworkable.

>We cannot sign contracts when we maintain deployed systems by just
>saving images and preying.

Yes. Make snapshots. And a good experiment to get tools improved
would be to add a ConfigurationOfPharo build that creates a version for
each build. I suspect some scalability issues.

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Units is now cleaned and can be managed with versionner.

Stef

On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 28/6/14 11:22, Stephan Eggermont wrote:
I know that.

>
> To make that work dependent configurations would need
> to change at the sum of change rate of all the configurations they are
> depending on.  As long as we don't have global flow (in the lean sense) that is
> unworkable.

this is what we will see. Again there is a difference between
development and release.
When you develop you want to always get the latest (and certainly not on
project you have no control over).
When you version clicking on a tool like versionner should work.

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Artefact was nicely working already well.

The development version points to the stable of Units (this is their
choice) and not the development.
The stable version points to the version 1.2 of Units.
Good work guillaume and olivier.

Stef

On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

For Merlin I promoted latest version as stable since it does not hurt.

Stef

On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

For Rubric I added a version + stable information



On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

RoelTyper configuration is nice and nothing to be done.

Stef

On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

SmallDude looks scary. The stable version is tagged as broken! Really
cool :) and is just from 2011 :)
Now I cleaned it.


I kept the dependencies to
     spec project: 'Moose Core' with: '5.0-baseline'.
for now.

Stef


On 28/6/14 11:21, stepharo wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Steph, please try this with ConfigurationOfPharo first.
You have much more control over that, and it will
allow you to break the tools fast without bothering
others. We use ConfigurationOfMoose.

>When you develop you want to always get the latest (and certainly not on
>project you have no control over).

You want to, but you can't. And you definitely don't want
to have to create all kinds of configuration versions of
packages outside your control just to be able to load.
I would like to include Torch. Doesn't work with latest.

Cleaning up of moose configuration is much appreciated.
You probably want to add some groups, so you can have your
tools.

Stephan

 






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Guille wrote
>Just a thought, maybe offtopic,
>but that goes in the modularity path...
>What about adding also a new ´moose´ tab
>to the configuration browser showing only
>moose sub-products?

configuration browser first needs something to be able to load Seaside with Magritte. We regularly get complaints about that. A separate tab for Moose doesn't make much sense. Configuration browser is for ease of use, so configurations should provide a list of sensible (to an end user) groups that the browser can use.

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stephan Eggermont wrote:

Guille wrote
  

Just a thought, maybe offtopic, 
but that goes in the modularity path... 
What about adding also a new ´moose´ tab 
to the configuration browser showing only 
moose sub-products?
    

configuration browser first needs something to be able to load Seaside with Magritte. We regularly get complaints about that. A separate tab for Moose doesn't make much sense. Configuration browser is for ease of use, so configurations should provide a list of sensible (to an end user) groups that the browser can use. 

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
  

I'd like to see the Configuration Browser having a tree interface and/or a context menu providing a list of groups & versions that can be installed. This would probably be dependent on some process like the PharoProjectCatalog CI scraping and compiling the packages
into one dataset that Configuration Browser wold work off.  Maybe I'll have a crack at this later on.
-ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev