3 Dec
2009
3 Dec
'09
7:57 p.m.
On Dec 3, 2009, at 6:51 PM, Simon Denier wrote:
my point is without we cannot do anything at ***all***.
with a map we could reason on it and perform semi automatic merging, testing....
Now we just load the latest version and pray.
At one point in time, we just know that the branch in which we are working may be ok
(partially, because we dont test everything). Meanwhile, there are plenty of other
changes. I just want to be clear that with this development process, we can not take any
development version as a precise picture of the status of Moose at the time of
development, because in general it is a branch.
sure then you flag it.
On 3 déc. 2009, at 13:56, Stéphane Ducasse wrote:
Let's be stupid: I can reload X Y Z, it's just not so easy sometimes.
come on simon. if we want to generate data automatically we cannot tinkle
for example for a new paper lukas rebuild all the pier versions since the beginning and
rerun all the tests and run the smalllint rules.
adrian could do the same
*About the Moose process*
I dont think the Pharo process and the Moose process compare.
I think that you are wrong. they both need a map. A specification of what to load
I do not see why saving XXX and not be able to reload XXX package is cool to your eyes.
It makes no sense!
with the current process:
you publish X Y Z and I put Y1 after
and you cannot reload your X Y Z so you are fucked up.
Now you say
map1 = X Y Z
and I say map2 = X Y1 Z
and we can all reload what you want.
You do not have to oppose map or absence behind a process.
You can publish map without having to run test.
With your approach we have no way to spot a vicious bug that requires to go back in
time.
In pharo sometimes we are forced to do that.
This is a technical problem and it has nothing to do with process. We should have maps.
You did not convince me :) The Pharo process is about integrating fixes from
packages which are supposed to do one and only one thing, and do it well and is tested.
The Moose process is about developers making incremental changes to the code base so that
they can work and share it immediately. Which means it can break other things.
Now I'm pretty sure I dont want a release every time someone commits a package in
Moose, because I'm pretty sure this someone didn't run all the tests before
committing. So making a release for each new commit makes no sense for me. We dont
integrate changes, we just merge when there are some divergent branches. That's why we
are always working with the dev version and the 'default' is one way to do it.
I disagree. Totally. If we want historical data about Moose, I guess
it's still possible to retrieve all latest packages at a given date. It will not be
very different from what we used at this date.
This is a crappy and bad way of doing that. This is a SVN regression. Let us study the
commit fingerprint to know what where the files
that worked together: but we know it and we have a tools to save it.
Now about the *release* process for Moose: sure I
would like that there will be more releases. Now as Doru said, when we do a release, we
should do it for every sub projects and it's bit difficult with the current tools.
- One way to do automatically it is to use the test server to at least create a new
version from the latest dev version and blessed it as 'tested' if 100% tests
passed or 'broken'
it will not work because we do not have good test coverage.
Now we know that a version is composed of a set of specific compoentns so just save it.
So I proposed something in a later mail about creating
'dev' version. Then one sould be careful it's a dev, not a stable version, so
I want a different name and different numbering schema like 1.3.x
probably.
Problem is I dont think Metacello can handle automatic
numbering.
Did not scale with Moose-All. Everytime someone committed Moose-All before you did, you
had to be careful with merging.
Yes
now we are not careful with merging at all.
It works by accident.
Now with a systematic map we have the same but in addition we can reproduce it and build
tools on top of it.
I can give a try and during the next two weeks damage Moose randomly you will see you will
have a terrible time to chase
them besides throwing away all the packages I commit. So this is clearly a clear lack of
maps.
But I dont want such versions to pollute the
manual versions, which are supposed to be stronger. So something like create automatically
'testedVersionXXX' with tests or broken as possible blessing.
We are talking about the wrong tool to fix the problem.
- Then we can do manual release from time to time
(every two weeks, every months?), which requires more work as we have to do it for the
different subprojects first, and blessed it as beta or stable.
come on
it worked in moose in store, it worked with Moose-all (modulo the subprojects even if I
prefered Moose-all than the current situation).
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev