Le 30 juin 2014 � 09:23, Diego Lont a �crit :
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're right, Versionner enforces a single workflow. We tried to do a simple tool that can fit most people and very easy to use. Versionner is far from perfect but allows to easily manage project dependencies and release for a "classical" workflow. There are also some known limitations (e.g., no support of platform-specific sections).
Versionner does not aim that ALL people use a single workfow but tries to provide guidelines. If one needs another workflow, it is possible by using Metacello directly. If needed, we can also add features to Versionner. It may be done from feedbacks.
To summarize, it is not "One Ring to rule them all" but rather one tool to fit more needs and make configuration management easy.
Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind.
The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know.
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.
True, it's really valuable. In the same time, it's difficult for people with few notions on SCM to know what to do.
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.
It is the same workflow that GitHub favors: you fork the code, do your changes and provide a pull request that will be accepted or not. It works quite well.
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.
I don't see your point here. What is really different except that you don't have an inbox (some kind of dedicated branch)? Instead, you publish in the same repository, creating new branches.
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.
Here, there is no review, ok.
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.
I can only agree. There is not one language for everything, one process for everything, one tool for everything => they are languages, processes, tools. Some of them more adapted to a given situation.
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?
Clearly not. Versionner was not thought to open all doors Metacello provides but rather provide a tool to manage easily configurations with a classical workflow.
That said, Versionner is not against any improvement / feature. If there are need uncovered, we should think on how to cover them.
3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too?
+1
And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ...
4. Modularity is very important.
+100
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.