A process proposal for 3.10

> > David T. Lewis wrote:
> >> On Mon, Oct 16, 2006 at 09:45:26PM -0700, Andreas Raab wrote:
> >>> Which brings me to the proposal I made earlier. The main goal of
> >>> that proposal is really to get away from the upfront feature
> >>> planning process and deal with the chaotic reality of open source
> >>> development by *embracing* it. So instead of feature list
> of things
> >>> that we SHOULD do, I'd like us to discuss things we HAVE done.
> >>> Instead of wishful thinking I'd like us to talk about all
> the cool
> >>> stuff that is actually happening!
> >> +1
> >> Dave
> >
> > +1 more, all that up front planning feels a lot like waterfall,
> > Smalltalker's most of all, should know better.
>
> It seems to me that your remark is not really in scope.
> If you look at 3.9 we set up a list of actions we wanted to
> have and we nearly did it. So....

>
> > And how long have we been waiting on 3.9?
>
> How many bug fixes did you propose?
> How many test did you wrote?
>
> > I'd much rather see a timely
> > release every 6 months that includes what's already been done,
>
> me too
>
> > than wait
> > forever for a release that has a list of "want to have's".
>
> Imagine that we delivered. But you can bash us, this is free,
> cheat and easy.
>
> We tried our best. Look at the gamma phase: nearly no
> feedback. And normally we should only fix show stoppers.
>
> I learned the lesson. This is a hard but I learn it.
>
> Stef

> > > +1 more, all that up front planning feels a lot like waterfall,
> > > Smalltalker's most of all, should know better.
> >
> > It seems to me that your remark is not really in scope.
> > If you look at 3.9 we set up a list of actions we wanted to
> > have and we nearly did it. So....
>
> And how long have we been waiting on 3.9?  I'd much rather see a timely
> release every 6 months that includes what's already been done, than wait
> forever for a release that has a list of "want to have's".

> Giovanni Corriga <[hidden email]> writes:
>> The problem with things like Etoys is that they're highly coupled  
>> with
>> the rest of the system, and part of the system depend on it. For
>> example, trying to remove Etoys triggers an emergency evaluator in
>> Squeak 3.9RC2. As I see it, if we want to remove Etoys (and either  
>> let
>> it rot in absence of a mantainer or turn it into an installable
>> package), those couplings would become bugs for the other package
>> mantainers.
>
> I agree with most of the thread.  Let me toss in, though, I am not
> convinced that EToys being intertwined is necessarily a terrible
> thing.  EToys is a lot of what makes Squeak, Squeak.
>
> You cannot unload the processes module from the Linux kernel.  This is
> not a bad thing, because processes are part of what makes Linux,  
> Linux.
>
> Also, keep in mind that all the Squeakland people are vitally
> interested in EToys.  There are ETosy-based text books, for goodness'
> sakes.
>
> I do agree that at least one steward for EToys needs to be identified,
> if there is not one already.  Try probing on the Squeakland mailing
> list, if nothing else.

> "Pavel Krivanek" <[hidden email]> writes:
> > Very good notes. This problems are described in the thread with Stef's
> > postmortem analysis
> > (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/109807.html)
>
>
> It is just painful reading Stephane's description of package slices.
>
> Why not use Package Universes to organize a collection of package
> versions?  There would be a 3.10 release universe.  The release team
> would know the update password, and they could update that universe
> with new package versions as they see fit.

>
> The main idea in the kind of process being suggested here is
> the value of decoupling the release process from the development process.
> You don't define the release in terms of what's in it,
> but rather in terms of how things get into it.
>
> How do you do that, when one feeds the other?
>
> The same way an airline decouples  its flight schedules from
> the passenger's process of getting their bags packed and getting their
> butts to the airport.
>
> You set up the release process as a small set of gating dates,
> and a set of criteria for what can pass through that "boarding" gate.
>
> I.e. declare that there's a release on April 2.
> To be in it, the development must be complete on December 2,
> and it must have integrated and passed tests by February 2.     (Just
> examples here.)
>
> All you know about that release now is that it might be different from
> the current one,
> if anything makes the dates, and that it -will- be released on April 2.
>
> Meanwhile, as a developer, if you want to contribute,
> you know exactly what needs to be done:
> the release process tells you how to get stuff into a release.
> That information is just those same gating dates and criteria.
> The criteria are usually about submission format,   quality,
> and who gets to issue 'tickets' for things you'd like to submit;
> usually there are gatekeepers for the broad functional areas,
> and they work in the usual consensus ways.
>
> So as a developer you know what you need to do, by when,
> and you know that if you do it, then you'll get that change into the
> release.
>
> If you want to make something that can't be ready for this release,
> or if you just don't make it, then no problem.  You try for the next one.
>
> The 'gating' criteria need to be clear and workable for both bug fixes
> and major surgery, so you usually express them in terms of stability;
> the usual form is that you'll take things if they don't cause regressions,
> and if the relevant gatekeeper(s)
> (whose allegiance is to a functional component, not the release process)
> recommends the change.
>
> This kind of process is usually called date-driven, or 'train';
> it's different than a content-driven approach in that dates determine
> content, rather than the other way around.
>
> A lot of organizations have found it a good way to untangle the knots
> when managing large releases that have a lot of separately-developed
> moving parts;
> you let the subsystems (sometimes just one or two guys) run their own
> processes.
> If they pack your bags on time, and make it through security,
> they get on the flight.
>
> There is art in it.  You have to manage the inflow and date staging
> so you don't flood the gating processes.   But the focus there is on
> understanding
> the integration and testing and other "boarding" processes, not on
> predefining the content.
>
> Anyway, I just thought a rundown from that pure-process point of view
> might be helpful.
>
> It's not there isn't a place for setting vision and goals;
> it's just that those aren't part of this kind of a release process.
> They're part of the development processes, which are separate.
>
> - brad
>
>
>
>> I basically agree.
>> So in my proposal I was trying to see on what I want to work (based on
>> the artefacts already there and also what could
>> be vision) and see if other people are willing too.
>> Just making the list of things that should be integrated and integrate
>> them is a lot of time.
>> In general I would love to stop harvest fixes and produce more fun
>> stuff (but may be I'm a housekeeper that like to
>> clean stuff), may be I should stop because my job is different now.
>>
>> Stef
>>
>>> Hi Giovanni -
>>>
>>> I fully agree with the meta goals of your proposal, namely to enable
>>> people to do their own development and to limit the amount of time
>>> spend on each individual part of the release.
>>>
>>> That said, I'm in almost complete disagreement with the rest of your
>>> proposal ;-) The fundamental flaw in it is that you are trying to
>>> commit other people's time. Starting from "the board appoints a
>>> release team" (phase 0) over "the teams announce the development
>>> plans" (phase 1) and "code will get dropped" (phase 2) up until "the
>>> VMMaker team will want to..." (the example) you're happy committing
>>> other people's time. In my experience this has *always* been a fatal
>>> error in a volunteer open source project.
>>>
>>> The *only* time you can commit is your own. And given that, how much
>>> of your proposal works if the only time that you can count on is your
>>> own? Even if we want to change the release process we cannot change
>>> some fundamentals about the environment we're in. And one of those
>>> fundamentals is that (on a scale where it matters) you can't tell
>>> people what to do. They're doing it voluntarily, they're doing it for
>>> their own reasons and trying to change that simply won't work.  To
>>> give a more concrete example, the maintenance work I do for FFI,
>>> Graphics, Balloon, and Compression packages is purely a volunteer
>>> effort. If you ask me about my "development plans" for the next six
>>> months, all I can say is "uhm ... ". Most importantly, because I have
>>> a fulltime job in a startup I for example couldn't possibly commit to
>>> a six months active development plan. It's simply not doable and even
>>> if it were I'd reject it on the grounds that unless you pay me for it
>>> I'm not going to treat this serious enough to make six month plans ;-)
>>>
>>> Both Stef and Markus understand that basic point. They both
>>> understand that in reality, all they can count on is their own time
>>> and they have reacted by investing more and more of their own time
>>> and effort in the process. And I would like us to change that process
>>> from one that leaves people burned out into one that can be done in a
>>> reasonable amount of time with a sustainable amount of energy.
>>>
>>> That change starts by admitting that we're all volunteers. Whether
>>> something will happen depends on so many factors that it's basically
>>> useless to try to do serious upfront planning for it. And again this
>>> is meant on scale - for each individual team it may make perfect
>>> sense but on scale I think you really can't.
>>>
>>> To emphasize that point even more I'll give you two recent examples:
>>> First, we have been talking for *years* about changing the source
>>> pointer in the methods. That it happens *now* is (from my point of
>>> view) exclusively due to the fact that we got a new sources file in
>>> 3.9 and lost the entire previous history for the single reason of the
>>> source limitations. Could anyone really have planned for that? I
>>> don't think so. Second, the SSL implementation we got recently. A
>>> while ago we started looking at SSL ourselves and decided to go with
>>> OpenSSL - we talked about Crypto team and their work but honestly, I
>>> would have called anyone a nut who would have told me that this stuff
>>> will be ready by now (I probably would have just laughed them out of
>>> the room). At least for me, this project came out of the blue,
>>> completely unforeseen and again nothing you could have possibly
>>> planned for.
>>>
>>> My point here is (in case you haven't guessed it by now) that in a
>>> volunteer community "planning" on the scale you are looking at is in
>>> many ways a futile exercise. Things happen for their own reasons at
>>> their own speed and not because you want them. And unless you want to
>>> put in endless amounts of energy by developing all the stuff that
>>> "your release" needs, you better find a way of dealing with that.
>>>
>>> Which brings me to the proposal I made earlier. The main goal of that
>>> proposal is really to get away from the upfront feature planning
>>> process and deal with the chaotic reality of open source development
>>> by *embracing* it. So instead of feature list of things that we
>>> SHOULD do, I'd like us to discuss things we HAVE done. Instead of
>>> wishful thinking I'd like us to talk about all the cool stuff that is
>>> actually happening!
>>>
>>> I think that this may be the only way to make sure we can survive the
>>> release process in a volunteer community like ours and it's
>>> surprisingly similar to what we did at SqC - the main difference is
>>> that SqC (instead of the community) picked which of the contributions
>>> got adopted and which ones didn't. At SqC (or any other commercial
>>> entity that I have been involved in) we have always been aware of
>>> error 33 and therefore never relied on the open source effort to
>>> produce specific results in a specific time frame. That's what
>>> companies do, that's why they take money to do it. However, anything
>>> that happened was always welcome and often a surprise. And I can say
>>> for sure that during those times nobody got burned out by the
>>> process.  And I think that process can be recreated.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>> Giovanni Corriga wrote:
>>>> Hi all,
>>>> since we've started discussing 3.10/4.0, I'd like to relay some
>>>> thoughts
>>>> that I've expressed some times ago on #squeak about a possible
>>>> development process for Squeak 3.10.
>>>> This proposal is based on two points:
>>>> - decentralization of development
>>>> - fixed duration of iterations ("timeboxing")
>>>> "Decentralization of development" means moving most of the
>>>> responsibility of development from the release team to the single
>>>> package mantainers (stewards). The release team should just be an
>>>> integrator of the code blessed by the stewards, and should facilitate
>>>> coordination between the stewards of different packages.
>>>> "Timeboxing" means having a fixed length release cycle, at the end of
>>>> which a new stable version is released. This means that if there are
>>>> some problems with a new feature, the deadline doesn't get postponed;
>>>> instead it's the feature that gets dropped from the current development
>>>> release and rescheduled for the next release.
>>>> How would this work? Here's a more detailed description.
>>>> -----------------------------------------------------------------------
>>>> PHASE 0: RELEASE TEAM FORMATION
>>>> The SqF board will appoint a release team for 3.10. This team will have
>>>> 3-7 members; 5 would be the sweet spot.
>>>> The first task for the release team will be to find a mantainer for
>>>> each
>>>> one of the packages currently in the image. If they can't find a
>>>> mantainer for a package, than said package _will get dropped from the
>>>> image_ without any further discussion.
>>>> PHASE 1: RELEASE PLAN
>>>> After having found mantainers for every package, there's a package
>>>> selection phase, during which the team and the maintainers:
>>>> - decide which packages currently in the image should get removed from
>>>> the image and turned into SqueakMap-loadable packages.
>>>> - decide which new packages can be added to the image or replace other
>>>> packages currently in the image.
>>>> Input from the community and the stakeholders will be taken into
>>>> account.
>>>> After deciding which packages will be in the 3.10 image, the release
>>>> team, the mantainers and the community will work on creating the
>>>> release
>>>> plan.
>>>> Each package mantainer will announce what it plans to do for 3.10. The
>>>> release team will integrate these proposals into a coherent release
>>>> plan, solving possible conflicts and coordination problems. The
>>>> community will be able to make comments and/or requests.
>>>> After all these steps, which shouldn't take more than a month, the
>>>> development of 3.10 can start.
>>>> PHASE 2: DEVELOPMENT
>>>> Development will have three stages:
>>>> - a 3 months alpha stage
>>>> - a 2 months beta stage
>>>> - a 1 month gamma/RC stage.
>>>> The deadline for each stage will be decided at the beginning of the
>>>> iteration.
>>>> Every week during each stage the release team will integrate the new
>>>> releases of each package blessed by the package mantainers.
>>>> Package mantainers will be the main responsible for development of
>>>> their
>>>> package and they'll be free to manage development as they like; ideally
>>>> they should create a development team.
>>>> If at the end of the alpha stage some of the work items of the plan
>>>> aren't near completion, _these items and the corresponding code will
>>>> get
>>>> dropped_. If this is not possible, the code will be kept in the image,
>>>> but it will have not to break the other code in the image.
>>>> During the beta and gamma stages, no new features will get added to the
>>>> image; only bug fixes can go in. During the gamma stage, only
>>>> showstopper bugs will be fixed; other bug fixes (eg. cosmetical fixes)
>>>> will be scheduled for 3.10.1.
>>>> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or
>>>> whatever) will get appointed and will work with the package mantainers
>>>> to form the release plan for the next version.
>>>> EXAMPLE
>>>> Here's a an example of how things could possibly work.
>>>> Release plan:
>>>> During phase 1, the various package mantainers propose work items. So
>>>> let's pretend that...
>>>>   - VMMaker team will want to:
>>>>     * integrate the async event patches useful for SqueakGtk.
>>>>     * integrate the Ffenestri code in all VMs, including the Unix one.
>>>>     * work with the Kernel team/maintainer on CompiledMethod cleanup.
>>>>   - Nebraska team will work on removing it from the image.
>>>>   - Pavel will want to work with various mantainers to integrate his
>>>> patches for his KernelImage system.
>>>>   - Tools team will want to:
>>>>     * better integrate AST and the Refactoring services.
>>>>     * make Omnibrowser the default browser.
>>>> Now let's pretend that at the end of the alpha stage, the Tools team
>>>> still hasn't produced an Omnibrowser based debugger. Since it's the end
>>>> of the alpha stage, the OBDebugger will be punted to the next release,
>>>> and 3.10 will have a class browser based on OB but still the old
>>>> debugger.
>>>> -----------------------------------------------------------------------
>>>> I believe a process such as the one I'm proposing can work and help
>>>> produce good quality releases.
>>>> I'd like to hear comments on this, even if they just say that my
>>>> proposal sucks.
>>>>     Ciao,
>>>>         Giovanni
>>>
>>>
>>
>>
>
>
>

> In your case, according to the process I'm proposing, you would just
> declare that you can't commit any predetermined time for the next six
> months.
> Now, what if a couple of months after your declaration you have some
> time to work on, say, Graphics, and you're able to produce new releases
> of that package? If when this happens 3.10 is still in alpha, your new
> releases could be included without many problems (excluding integration
> problems, that is); if in beta or gamma, then your changes should be
> moved to the next version. But this would not forbid you to work on it;
> it would just postpone its integration.

> The SqueakLand people don't use 3.9, and I am quite sure they never will.
>
> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
> image for eToys1.
>
> For the future, there needs to be a new eToys2 that is maintainable.
> There is a very cool demo of a next-gen eToys based on Tweak.
> That seems, to me, much more the thing to take a look at for the future
> eToy system.
>
>        Marcus

> When resource is scare, the smarter come out ;)
>
> How is big etoys?
> And How is deeply integrated in Squeak?
>
> If Etoy is not so big (as I remembered), we can simply start to "cut its
> wires" from Morphic and let it aging around.
> We can start creating a mechanism to deprecate some methods.
> By the way the deprecation engine seems to me very important to do.
>
> We can do this thing with less then 8 hours of work in my own opinion,
> I suggest to rethink our apprach and to adopt a "Panta Rei" (verything
> changes - the philosophy of Heraclitus).
> We should start to plan the new Squeak version WITHOUT throwing away the
> bad
> things.
>
> We can start taking bad thing alone in a room, putting heavy doors in it,
> and then
> prohibing them to exit :)
>
> The other developers will start stopping using EToy in a smooth way.
>
> After a while we can think how to dismiss them... or not.
>
> In my own opinion frequently Squeak home change, so the problem will solve
> smootly without so much pain.
> Let's discuss on this approach.
>
>
> On 10/18/06, Juan Vuletich <[hidden email]> wrote:
>>
>> So, this seems a good time to remove eToys from the official release. I
>> can team with Pavel and Stef (and any other volunteer) to do this.
>>
>> However, it will take some 20 or 30 hours of work, and I think we need
>> to know if this will be adopted, otherwise I won't spend time on it.
>>
>> I guess the Board could lead, and make a decision, or enlight me about
>> the decision process for issues like this one.
>>
>> Cheers,
>> Juan Vuletich
>>
>> Marcus Denker wrote:
>> > The SqueakLand people don't use 3.9, and I am quite sure they never
>> will.
>> >
>> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
>> > image for eToys1.
>> >
>> > For the future, there needs to be a new eToys2 that is maintainable.
>> > There is a very cool demo of a next-gen eToys based on Tweak.
>> > That seems, to me, much more the thing to take a look at for the
>> future
>> > eToy system.
>> >
>> >        Marcus
>>
>>
>
>
> --
> "Just Design It" -- GG
> Software Architect
> http://www.objectsroot.com/
>
>

> Giovanni Giorgi puso en su mail :
>
>> We can do this thing with less then 8 hours of work in my own opinion,
>
>
> Juan have a deep knowledge about this, and still could take more time.
> It¹s not cutting in Jack the Ripper style what was needed.
> Also for Nebraska.
> I do some attempt in former Morphic Team , but was not good enough for be
> approved.
> The road to Zen Squeak with some of gestallt is loooong , full of rocks
> but
> one what deserves .
>
> Edgar
>
>

> Hi Giovanni,
>
> I don't think what you say is doable. We don't have the means to  
> break all
> dependencies on eToys, and at the same time keep eToys working. It  
> would
> need the same kind of work as to make it unloadable and loadable back.
>
> When I realized how much refactoring is needed to do that, I  
> stopped the
> MorphicSplitters effort and quited as the Morphic Steward.
>
> What I propose can be done. I did it for 3.7. You can download it from
> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ 
> EtoysFreeMorphic.html . I
> believe Pavel did something similar (although I haven't looked at it.
>
> Anyway, I'd like to be proven wrong. Are you volunteering?
>
> Cheers,
> Juan Vuletich
>
>> When resource is scare, the smarter come out ;)
>>
>> How is big etoys?
>> And How is deeply integrated in Squeak?
>>
>> If Etoy is not so big (as I remembered), we can simply start to  
>> "cut its
>> wires" from Morphic and let it aging around.
>> We can start creating a mechanism to deprecate some methods.
>> By the way the deprecation engine seems to me very important to do.
>>
>> We can do this thing with less then 8 hours of work in my own  
>> opinion,
>> I suggest to rethink our apprach and to adopt a "Panta  
>> Rei" (verything
>> changes - the philosophy of Heraclitus).
>> We should start to plan the new Squeak version WITHOUT throwing  
>> away the
>> bad
>> things.
>>
>> We can start taking bad thing alone in a room, putting heavy doors  
>> in it,
>> and then
>> prohibing them to exit :)
>>
>> The other developers will start stopping using EToy in a smooth way.
>>
>> After a while we can think how to dismiss them... or not.
>>
>> In my own opinion frequently Squeak home change, so the problem  
>> will solve
>> smootly without so much pain.
>> Let's discuss on this approach.
>>
>>
>> On 10/18/06, Juan Vuletich <[hidden email]> wrote:
>>>
>>> So, this seems a good time to remove eToys from the official  
>>> release. I
>>> can team with Pavel and Stef (and any other volunteer) to do this.
>>>
>>> However, it will take some 20 or 30 hours of work, and I think we  
>>> need
>>> to know if this will be adopted, otherwise I won't spend time on it.
>>>
>>> I guess the Board could lead, and make a decision, or enlight me  
>>> about
>>> the decision process for issues like this one.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> Marcus Denker wrote:
>>>> The SqueakLand people don't use 3.9, and I am quite sure they never
>>> will.
>>>>
>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
>>>> image for eToys1.
>>>>
>>>> For the future, there needs to be a new eToys2 that is  
>>>> maintainable.
>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>> That seems, to me, much more the thing to take a look at for the
>>> future
>>>> eToy system.
>>>>
>>>>        Marcus
>>>
>>>
>>
>>
>> --
>> "Just Design It" -- GG
>> Software Architect
>> http://www.objectsroot.com/

> As Juan wrote, removing Etoys from Morphic while keeping it both
> loadable and functioning properly is futile.
>
> So either you leave it in, or you consciously give up compatibility
> with anyone using Etoys now, like the squeakland distribution, OLPC
> distribution, Smalland, the Spanish LinEx version, the Japanese
> Nihongo version etc. Already synchronizing Squeakland and 3.8 was
> hard, nobody has tried yet for 3.9, but this would make it outright
> impossible.
>
> I'm *not* saying you should not do this, but please be aware of the
> possible consequences.
>

> As I have understood, there is a new eToy implementation in progress
> inside
> Tweak.
> We can wait until this implementation is a bit stable.
> When this will be true, the other part depending from eToy1 will be able
> to
> migrate to eToy2.
> After that we can start to deliver an official squeak distribution with
> eToy2 and eToy1 side by side.
> Then after w ahile we can start to evict eToy1.
>
> This will save some efforts, at cost of a bit larger image (but avoiding
> some hours of work can be a good exchange ;)
>
>
> On 10/18/06, [hidden email] <[hidden email]> wrote:
>>
>> Of course.
>>
>> That's why I'm asking the Board to decide, or advice.
>>
>> Cheers,
>> Juan Vuletich
>>
>> > As Juan wrote, removing Etoys from Morphic while keeping it both
>> > loadable and functioning properly is futile.
>> >
>> > So either you leave it in, or you consciously give up compatibility
>> > with anyone using Etoys now, like the squeakland distribution, OLPC
>> > distribution, Smalland, the Spanish LinEx version, the Japanese
>> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was
>> > hard, nobody has tried yet for 3.9, but this would make it outright
>> > impossible.
>> >
>> > I'm *not* saying you should not do this, but please be aware of the
>> > possible consequences.
>> >
>>
>>
>>
>>
>
>
> --
> "Just Design It" -- GG
> Software Architect
> http://www.objectsroot.com/
>
>

> As I have understood, there is a new eToy implementation in  
> progress inside Tweak.
> We can wait until this implementation is a bit stable.
> When this will be true, the other part depending from eToy1 will be  
> able to migrate to eToy2.
> After that we can start to deliver an official squeak distribution  
> with eToy2 and eToy1 side by side.
> Then after w ahile we can start to evict eToy1.
>
> This will save some efforts, at cost of a bit larger image (but  
> avoiding some hours of work can be a good exchange ;)
>
>
> On 10/18/06, [hidden email] <[hidden email]> wrote: Of  
> course.
>
> That's why I'm asking the Board to decide, or advice.
>
> Cheers,
> Juan Vuletich
>
> > As Juan wrote, removing Etoys from Morphic while keeping it both
> > loadable and functioning properly is futile.
> >
> > So either you leave it in, or you consciously give up compatibility
> > with anyone using Etoys now, like the squeakland distribution, OLPC
> > distribution, Smalland, the Spanish LinEx version, the Japanese
> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was
> > hard, nobody has tried yet for 3.9, but this would make it outright
> > impossible.
> >
> > I'm *not* saying you should not do this, but please be aware of the
> > possible consequences.
> >
>
>
>
>
>
>
> --
> "Just Design It" -- GG
> Software Architect
> http://www.objectsroot.com/
>