Your response shows that I have not made my point well. I wanted to
point out that we need different workflows because of the different
demands. A workflow is more than only a tool, but starts with people
building something and ends with people using something. And you point
out that versioner has one workflow implemented, and therefor will not
be applicable to all projects.
A. For pharo core all projects are included in pharo. The number of
external influences (VM, plugins) is very limited. It works here to
have no configuration at all, since there is only 1 release-branch:
the current one. And since the file server creates a version of each
build, we can always go back to a specific build. Quality is very
important to pharo as a lot of users depend on a good working pharo.
But it should not be like that! Pharo should be modular too. And we need
to have configurations.
Why we cannot have better tools based on Roassal because we do not want
to have a monolithic solution.
So we should have a modular image and tools and process to get there.
B. For the “cross-platform” projects this workflow is not sufficient,
because there are much more external influences. So here we use the
configurations to manage the releases. And the complexity of the
configuration of Seaside shows this is a very complex thing to do.
This complexity is not from Metacello. Metacello allows us to do a
decent job here for the supported platforms. For the unsupported
platforms there is some additional manual work involved, with all
risks to this. The complexity here stems from the Software
Configuration challenges Seaside faces. A simple inbox won’t do the
job for us. Quality here is also very important as a lot of users
depend on a good working Seaside. Also there are more demands on
reproducibility, as there are quite some systems depending on Seaside
that should function 24/7.
C. For the “moose” projects, we have a few advantages above the
cross-platform projects, and a few disadvantages:
+ Moose only needs to work for pharo. So we can cut out a lot of
platform specific junk. Some projects are suited for multiple
platforms, but not for the amount of platform Seaside should work on.
+ There are far less projects depending on Moose. Most of them are
integrated, so tests will automatically be fired. And the projects
that do depend on Moose usually do not have run 24/7.
- Moose depends on more projects then Seaside. To create an exact
version is therefor much harder.
- A large part of the Moose bugs comes from the change rate of the
projects Moose depends on. Pharo has a very drastic strategy to
improve its architecture. This causes quite some maintenance work.
So that there is no review is not the point. The point is that because
of these different demands we need to accept a lower quality standard
for moose. This lower quality standard is maybe undesirable, but is
not easily improved. Having no review is a consequence of this, not
the cause. If we want to improve this quality standard, better SCM
tools will not suffice. On the other hand, this lower quality standard
has so far worked for Moose, as there are less people who depend on Moose.
Regards,
Diego
