On 30/6/14 09:23, Diego Lont wrote:
I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started.

I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded.
You can always use Metacello.
Versionner is here to help. When a system offers to many freedom we need patterns. Versionner is here to
focus on the 90% of the cases that help people.


1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows:
A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards.
We do not use metacello (unfortunately) for Pharo.

B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a “released” version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues.
C. For the “moose” projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes.

I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale):
When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported.
Yes.

2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this?
I dream about a simpler metacello because christophe got hard times on it.
Versionner is not for Pharo for the moment. Pharo will probably use the same process that I describe.
in dev load from the baseline
release freeze version
this is orthogonal to the notion of inbox.

4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem.

Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways.

5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures.

I know that well so this is why I do not want to fork but we should move in the right direction and we are so everything look
good to me.


Regards,
Diego


_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev