I just don't see it the way you do. For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it. What stops anyone from implementing his own configuration tool ?
On Mon, Jun 30, 2014 at 10:23 AM, Diego Lont <diego.l...@delware.nl> 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. > > 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. 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. > 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. > > 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? > > 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? 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. 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. > > Regards, > Diego >
