development workflow for GTools (GToolkitCore)
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 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? nicolai
Would it be possible/desirable to have a system such that: * bug fixes for external packages can be still be directly applied and tested in the Pharo-integrated branch * the CI workflow generates an updated ConfigurationOf{external package} that it pushes back to the external package repository? Its a great idea to separate out Configurations to devolve responsibility for sub-packages, but it adds some friction to bug fixing. It "seems" we will have a single branch combining both feature development and bug-fixing, but it would be nicer to have two branches. --------------- On another track, I wonder if it would be useful if a package which is part of a Configuration is made dirty, the Configuration itself could also be marked dirty? cheers -ben On Fri, Feb 6, 2015 at 4:36 AM, 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 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?
nicolai
Would it be possible/desirable to have a system such that: * bug fixes for external packages can be still be directly applied and tested in the Pharo-integrated branch * the CI workflow generates an updated ConfigurationOf{external package} that it pushes back to the external package repository? Yes this is the process I had in mind but this is not that simple because the configuration of the external package may also have changed and a merge should be done in the external package. Its a great idea to separate out Configurations to devolve responsibility for sub-packages, but it adds some friction to bug fixing. Yes I always thought about it.
It "seems" we will have a single branch combining both feature development and bug-fixing, but it would be nicer to have two branches.
--------------- On another track, I wonder if it would be useful if a package which is part of a Configuration is made dirty, the Configuration itself could also be marked dirty?
cheers -ben
On Fri, Feb 6, 2015 at 4:36 AM, Nicolai Hess <nicolaihess@web.de <mailto: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 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?
nicolai
On Sat, Feb 7, 2015 at 4:24 AM, stepharo <stepharo@free.fr> wrote:
Would it be possible/desirable to have a system such that: * bug fixes for external packages can be still be directly applied and tested in the Pharo-integrated branch * the CI workflow generates an updated ConfigurationOf{external package} that it pushes back to the external package repository?
Yes this is the process I had in mind but this is not that simple because the configuration of the external package may also have changed and a merge should be done in the external package.
I considered that, but unless our workflow is constrained to having only a single branch we need explore this space. Consider Package A has a core group of people working towards its next feature on its development branch, and a third-party submits a bug fix for Package A. Do we need to wait for the next feature to be ready for integration to get the bug fix, and in one hit get feature+fix (a), or do we want the fix integrated asap after suitable review, and integrate the feature separately in its own time (b). In either case there will be a PackageA-thirdparty.#.mcz that needs to merged. Its just a question of when its merged. Now if I am the third-party, the latter option (b) seems a faster and more transparent turnaround which is more motivational. So I haven't experienced much with distributed multi-party workflows. I only know the ones I read related to git. Here it seems the common workflow is for the feature branch to merge the master into itself before pushing itself to the master. This seems to align with option (b). I feel a bit that how we have a single versioned file for Configuration is the bottleneck for the workflow of managing develop paths outside the master image. Sure multiple branches can be defined within that file, but it seems awkward for multiple parties to manage those branches without stepping on toes. My musings lead me to the following analogy with git: * The way that multiple branches are defined within the Configuration file seems like the metadata defining a cloned git repository. It defines the versions for the heads of the various branches. * Multiple parties updating the single ConfigurationOfA-name.#.mcz file is like multiple parties working in the same cloned git repository. * Copying the ConfigurationOfA-name.#.mcz to ConfigurationOfA-Pharo-name.#.mcz would be like cloning a repository. Its a copy of the repository branch metadata. * These files ConfigurationOfA-name.#.mcz and ConfigurationOfA-Pharo-name.#.mcz could still be stored in the same server location, similar to how github holds multiple repository clones, but the heads of the branches could progress independently in each clone. * What we would need is a way to merge a Configuration's dependencies similar to how we merge and display a Slice's dependencies (making the workflow like merging a pull request between cloned repositories). What do we currently have like that? cheers -ben
Its a great idea to separate out Configurations to devolve responsibility for sub-packages, but it adds some friction to bug fixing.
Yes I always thought about it.
It "seems" we will have a single branch combining both feature development and bug-fixing, but it would be nicer to have two branches.
--------------- On another track, I wonder if it would be useful if a package which is part of a Configuration is made dirty, the Configuration itself could also be marked dirty?
cheers -ben
On Fri, Feb 6, 2015 at 4:36 AM, 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 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?
nicolai
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). 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/ But, could the Monkey not be able to run all tests before an integration of the development version? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
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"
Hi, On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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.
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
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"
2015-02-20 16:59 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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.
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"
On Wed, Feb 25, 2015 at 10:08 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-02-20 16:59 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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.
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)
Added all except TraitTest. Cheers, Andrei
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"
Doru with versioner you can release in a click... Le 8/2/15 13:01, Tudor Girba a écrit :
Hi Nicolai,
On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess@web.de <mailto: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). 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/
But, could the Monkey not be able to run all tests before an integration of the development version?
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Unfortunately, you cannot release with one click multiple deeply nested configurations. We will have to solve this problem soon :) Cheers, Doru On Sun, Feb 22, 2015 at 8:33 PM, stepharo <stepharo@free.fr> wrote:
Doru with versioner you can release in a click...
Le 8/2/15 13:01, Tudor Girba a écrit :
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). 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/
But, could the Monkey not be able to run all tests before an integration of the development version?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
participants (5)
-
Andrei Chis -
Ben Coman -
Nicolai Hess -
stepharo -
Tudor Girba