2015-02-08 13:01 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess@web.de> wrote:
14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools #development "From this version onwards the development version should be integrated."
Is this a good idea? Does the #development version always include *all* the latest changes, because after Andrei opened 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools (which got integrated in 40475) I uploaded some changes for issue 14608 <https://pharo.fogbugz.com/default.asp?14608> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter methods I set the status to "Fix Review needed",
but my changes are integrated in 40475 too!
I think that in the current situation, it is actually a good idea. And yes, the integration does include all latest versions of GT-related packages.
Before changing to development, we required a stable release for the integration. That implied: 1. creating a stable release and 2. integrating it in the Pharo through a separate issue.
Yet, in GT we all work on the very latest version, and creating a "stable" release is somewhat artificial given the speed at which things are changing now. Creating the "stable" version also led to delays between a fix in GT and an integration in Pharo (sometimes measured in weeks).
It still takes weeks. the last GToolkitCore integration was 3 weeks ago.
So, in the case of GT requiring the stable release did not provide any added value, but it has the negative consequence of delays.
I am not satisfied with the way external packages are handled.
1. if there is not one slice/changeset per issue, it is even less likely someone will review the changes. 2. you don't know who works when on a issue. They are solved in a bulk. 3. a new configuration might not only includes bugfixes but new features as well. 4. often we have unbound globals / undeclared references or other test failures.
Can we use the build server for those external projects (like GToolkitCore, Athens, TxText), and that if a project makes a new configuration, it uses the same issue validator for loading and testing that configuration?
We already have a GToollkitCore job, but it only runs the GT tests. Perhaps this is not enough? https://ci.inria.fr/moose/job/gtoolkitcore/
It would be nice if it runs some of the image validation tests ReleaseTest ClassTest BehaviorTest ... That way we can we see early enough, if GT-Extensions will break some validation rules (unresovled externals / Obsolete classes / Polymorphism Trait/Class)
But, could the Monkey not be able to run all tests before an integration of the development version?
I don't know if the Monkey can load Configurations.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"