phil@highoctane.be wrote:
On Fri, Mar 28, 2014 at 8:17 PM, Ben Coman <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
Looks like a lot of people are going to be running patched versions if the release goes without some enhancements.

What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ?

(Let's make the name shorter but you get the idea).

Phil

I wonder if it would be more or less effort to operate a "hot fix" facility between releases. By this I mean, after Pharo 3 release all slices fixing Pharo 3 bugs are based off the static release. This might have the advantages that:
* Users get to select the bug fixes important to them
* Ergo, users can can avoid bug fixes not relevant to them that might have unintended consequences in production.
* Bug fixes don't go stale when fixed in the released Pharo 3 but the Pharo 3 builds have progressed a lot.
* Users don't have to decide between waiting for a the next Pharo 3 minor-release, or tracking a moving target with continued evolution of "latest" Pharo 3 after release.
* The part of the community that wants longer term support for systems in production could take a greater role in maintaining Pharo 3, while the core focus moves on to Pharo 4.

A simple process might be tagging such resolved issues in Fogbugz as as 3.0-hotfix. Alternatively a tool like the Configuration Browser might list them in image. That tool could be installed from the Configuration Browser as ConfigurationOfHotfix. 

The downside would be more difficulty in packaging hotfixes together for a minor-release.  However over time hotfixes might be consolidated into other hotfixes, and the greatest of these becomes the basis for the minor-release.

Just a passing thought.
cheers, Ben


A hotfix tool would be the other side of the Kommiter coin.
So, Hotfixer?

With a UI showing slices for which the status in FogBugz would be "hotfix30"
Or a list of HOTFIX- in Pharo/Pharo30Hotfix/ in Smalltalkhub.

Ah, let's make something for getting the ball rolling: http://www.smalltalkhub.com/#!/~Pharo/Pharo3Hotfix

So,a HOTFIX shall possibly combine SLICEs or packages in a proper loading order and postscripts (like the one of Ben).

I am currently writing some package loading code for my own use, this would be a nice opportunity for me to do a Spec based tool.

Wanna join forces, people?
Phil 
Hi Phil,

Your enthusiasm is encouraging and makes me think deeper.  It was a passing thought and there are a few conceptual things to sort out that need community support. 
* An important consideration is minimizing burden on the limited integration resources.  In particular, just to state the obvious, it should not run in parallel with the mainline development e.g. Pharo4.
* Where you say "combine SLICEs or packages in a proper loading order" - that exceeds my intention (open to discussion).  That "feels" like a duplication of the existing mainline slice integration process and Metacello configurations. 
* This might have the narrow scope of supporting production systems**.  The same concerns expressed in the "Release Mode" thread that "any change" is dangerous apply doubly for production systems.  While the Pharo 3 mainline will progress towards Pharo 3.1 with consecutive integration of issues A, B, C & D, a production system may want to cherry pick only issue C and live without A, B & D.  Now someone would need to pick issue C out of the integration stream and test against Pharo 3 Release, but once that is done, it would be useful for others to leverage it. 
* The key difference then between a SLICE and a HOTFIX is that a SLICE is tested against the latest moving mainline, while a HOTFIX is tested against a particular static Release. However there is no guarantee that hotfixes work together.  In the first instance (until its clear the communities finds hotfixes a useful strategy) I'd simply handle dependencies between hotfixes by documentation or by producing another hotfix encompassing all required slices. 
* A useful tool would be one that reported to a central database which combination of hotfixes are commonly installed together, to help users judge which they might want to install.
* I am rethinking basing this off Fogbugz statuses, since I realised it might work with existing infrastructure without introducing that as an added element of complexity.  For example, as shown in the attached snapshots, when saving slices you can change the name of the slice.  Then you could browse HOTFIXes and their description using Monticello. 
* Now I haven't used Kommiter yet, so maybe I am missing a vision of the opportunities there.

Up until Pharo 3 Release I think its important to spend my free evenings tackling what remaining TODO issues I can.  By its nature, a hotfix is intended to operate against a static release, so there is no rush to get it done before Pharo 3 Release. 

** Disclaimer, I don't actually have any production Pharo systems.  I've only supported them for other software in the past.  Others with production Pharo systems should speak up.

cheers -ben