2015-02-20 16:59 GMT+01:00 Tudor Girba <[email protected]>: > Hi, > > > On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <[email protected]> wrote: > >> >> >> >> >> 2015-02-08 13:01 GMT+01:00 Tudor Girba <[email protected]>: >> >>> Hi Nicolai, >>> >>> >>> >>> On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <[email protected]> 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. >> > > That's because of two reasons: (1) we did some changes that took longer, > and (2) by the time we were ready to commit the jenkins went off. So, this > time it is not so representative. We do want this to happen faster. > > > >> >>> 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 >> ... >> > > It now runs the ReleaseTest. We can add the ClassTest and BehaviorTest. > What other tests should we add? > > Doru >
Given that extensions like GTInspector and GTSpotter often extent core classes I would run at least these tests: ReleaseTest ClassTest ClassDescriptionTest BehaviorTest (TraitTest - this is awfully slow) > > > >> 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" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
