On Fri, Feb 25, 2011 at 9:50 PM, Stéphane Ducasse
<[hidden email]> wrote:
Hi guys
1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and the rest.
Yes
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 visible).
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
future?
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 (ex: Zinc).
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.
Agree.
Laurent.
Stef