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 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 Integrate GTools (which got integrated in 40475)
I uploaded some changes for issue
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