New subject: [Pharo-dev] Versioner

30 Jun 2014

Hi Christophe,

...
  Hi Diego,

 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. 
That is exactly my point. But Stef currently tries to enforce this workflow of working to
Moose. And since this workflow will not work well for Moose (because of the demands on the
process), I object to this.

...
   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. 
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.

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

Re: [Pharo-dev] Versioner