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. 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. So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future? 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. Stef
I think that is reasonble but I also think that at least you should give the people working on the issues (like Dale's solo sprint) a couple of day to sort all the issues. What about this, let people until monday and then release the tuesday at the end of day. Cheers El vie, 25-02-2011 a las 21:50 +0100, Stéphane Ducasse escribió:
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.
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.
So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future?
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.
Stef
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Hi Stef, I think this is the right approach. I would suggest in the future to set a hard deadline a month before, and only include what works at that time. Like this people have time to react, and if they do not, you can safely remove things without anyone telling you that you did not warn them :) Cheers, Doru On 25 Feb 2011, at 21:50, Stéphane Ducasse wrote:
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.
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.
So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future?
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.
Stef
-- www.tudorgirba.com "What is more important: To be happy, or to make happy?"
Yes we should do that. Now the problem with the xml package is not even that. If we include package like that then for example each time a project like moose which use it wants to use the latest version (it will happen during at least 6 months) then they/we will have a problem because the system may have problem to load (we got that situation in Moose). So the SOLUTION is let people decide what they want to use. Keep PharoDev for tools not framework. Stef On Feb 26, 2011, at 10:16 PM, Tudor Girba wrote:
Hi Stef,
I think this is the right approach. I would suggest in the future to set a hard deadline a month before, and only include what works at that time. Like this people have time to react, and if they do not, you can safely remove things without anyone telling you that you did not warn them :)
Cheers, Doru
On 25 Feb 2011, at 21:50, Stéphane Ducasse wrote:
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.
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.
So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future?
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.
Stef
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Why do you think the break of 1.1 build is xml related? To me it appears either a PharoSound or metacello problem. The build is unable to load Collections-Arithmetic. Either it is missing from the package-cache or erronously pulled in via dependency that is not right. Norbert Am 25.02.2011 um 21:50 schrieb Stéphane Ducasse <stephane.ducasse@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.
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.
So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future?
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.
Stef
On Feb 27, 2011, at 1:06 AM, Norbert Hartl wrote:
Why do you think the break of 1.1 build is xml related?
This is what marcus was saying. May be the configuration did not point to the right version.
To me it appears either a PharoSound or metacello problem. The build is unable to load Collections-Arithmetic. Either it is missing from the package-cache or erronously pulled in via dependency that is not right.
ok Still this is an EXAMPLE of the kind of problems the infrastructure should fix. Let us focus on distributions based on metacello. Stef
Norbert
Am 25.02.2011 um 21:50 schrieb Stéphane Ducasse <stephane.ducasse@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.
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.
So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future?
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.
Stef
On Fri, Feb 25, 2011 at 9:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
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
participants (5)
-
laurent laffont -
Miguel Cobá -
Norbert Hartl -
Stéphane Ducasse -
Tudor Girba