[Pharo-project] About 1.2
laurent.laffont at gmail.com
Sun Feb 27 09:10:29 CET 2011
On Fri, Feb 25, 2011 at 9:50 PM, Stéphane Ducasse <stephane.ducasse at inria.fr
> Hi guys
> 1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and
> the rest.
Now for PharoDev we want to remove packages that are not about tools.
> If you want XML, openDBX... help us using Metacello to build distributions
> = something that will work in 1.2 when
> we will be in Pharo 10. Right now this is not normal that a problem in XML
> in 1.2 impacts the builds in 1.1.
How can XML in 1.2 impacts 1.1 ???????
> Proposing bloated images DOES NOT HELP US. Why? Because the goal is to have
> an INFRASTRUCTURE to take
> a small image with a metacello description repository and load whatever we
> want. In the future we want to use
> metacello to manage core and not to have a distinction between core and
> dev. We should be able to load all the time
> RBEngine and use it all the time to fix the system.
> Right now we are LOSING TIME on fixing 1.2 configs while we should invest
> in the infrastructure that will enable
> to be agile and load whatever configuration we/you will develop.
Yes. For the positive side, Hudson has given us visibility, which wasn't the
case in 1.1. And when you get visibility, the first thing you see is crappy
stuff :) IMHO 1.2 release process is far better than 1.1 (ok slow, but
I've changed my mind about XML. If Pharo's goal is to be a development tool,
then I agree to remove XML, it's not a dev tool.
But I think Mocketry should be back at least for 1.3. Mocks are a dev tool.
I want to put dependencies on Mocketry (as I know how to use it now and I
like it) for my projects but some are included in Pharo (ProfStef, Autotest)
and I'm waiting for a mocking library in Pharo. TDD without mocks is a pain.
Writing its own mocks is a burden.
So can we be focus on the infrastructure? The concept and tools that we will
> make us be really powerful in the
For Pharo as a dev platform, it seems infrastructure is here. The thing I
don't like is that for PharoCore 1.3 more and more tests actually fails.
IMHO, resolving failing tests must be the highest priority. And it's hard to
work on Pharo 1.3 failing tests if tests are failing in PharoCore. This way
we will improve the release process (continuous delivery in mind).
Now we need to be sure that often used frameworks (XML, Seaside, OpenDBX,
Magma ...) work out of the box for Pharo. So Pharo-Clients on Hudson is a
good idea. We need more. It's also a good tool to evaluate future inclusion
I like the Linux project process: fixed time frame ( 2 weeks) to include new
things, then resolve. They managed to get a major release every 3 months.
Don't start next major version until the current is out.
So if the community does not hear our call, we the board will take actions.
> We do not want to do that but if this
> is necessary we will do it because we want 1.2 to get out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project