About 1.2
Locked
 
|
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 |
|
|
In reply to this post by Stéphane Ducasse
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?" |
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]>: > 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 > > |
|
|
In reply to this post by Tudor Girba
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?" > > |
|
|
In reply to this post by NorbertHartl
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 <[hidden email]>: > >> 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 >> >> > |
|
|
In reply to this post by Stéphane Ducasse
On Fri, Feb 25, 2011 at 9:50 PM, Stéphane Ducasse <[hidden email]> wrote: Hi guys Yes Now for PharoDev we want to remove packages that are not about tools. 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
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 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 Agree. Laurent. Stef |
|
|
In reply to this post by Stéphane Ducasse
On Feb 27, 2011, at 9:11 AM, laurent laffont wrote: It's not XML, there is another problem. Status: => 1.2 now builds, without Mocketry. But that has been fixed in the meantime, so we can add it back. (it seems removing is a far better way to get people to fix something than anything else. I will do the same with the MethodWrapper package, you will see how quickly this gets fixed *after* removing it, but never without removing it...) => 1.1 does not build. I don't know why. *first* release 1.2, *than* release 1.1.2... => From the test side of things, there are only two things left in 1.2 -> MethodWrappers has test that fails 50% of the time. This will be solved by removing the package. -> there are Obsoletes after running tests. here I think as this is only after running tests, we can defer to 1.3 and remove the test for obsoletes in 1.2 Besides that, there are a number of things that need to be done for 1.2, they are listed here: 1.2 can only be released if this list is empty. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
I think that I fixed the issue with Shout.
I'm trying to load Pharo configuration now :( Stef >> >> >> >> How can XML in 1.2 impacts 1.1 ??????? >> >> > It's not XML, there is another problem. > > Status: > => 1.2 now builds, without Mocketry. But that has been fixed in the meantime, so we can add it back. > (it seems removing is a far better way to get people to fix something than anything else. > I will do the same with the MethodWrapper package, you will see how quickly this gets fixed > *after* removing it, but never without removing it...) > > => 1.1 does not build. I don't know why. *first* release 1.2, *than* release 1.1.2... > > => From the test side of things, there are only two things left in 1.2 > -> MethodWrappers has test that fails 50% of the time. This will be solved by removing the package. > -> there are Obsoletes after running tests. here I think as this is only after running tests, we can defer > to 1.3 and remove the test for obsoletes in 1.2 > > > Besides that, there are a number of things that need to be done for 1.2, they are listed here: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > 1.2 can only be released if this list is empty. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > |
|
|
I saw your changes and they did appear to be consistent with the changes I had made ...
Dale On Feb 27, 2011, at 1:56 PM, Stéphane Ducasse wrote: > I think that I fixed the issue with Shout. > I'm trying to load Pharo configuration now :( > > Stef > >>> >>> >>> >>> How can XML in 1.2 impacts 1.1 ??????? >>> >>> >> It's not XML, there is another problem. >> >> Status: >> => 1.2 now builds, without Mocketry. But that has been fixed in the meantime, so we can add it back. >> (it seems removing is a far better way to get people to fix something than anything else. >> I will do the same with the MethodWrapper package, you will see how quickly this gets fixed >> *after* removing it, but never without removing it...) >> >> => 1.1 does not build. I don't know why. *first* release 1.2, *than* release 1.1.2... >> >> => From the test side of things, there are only two things left in 1.2 >> -> MethodWrappers has test that fails 50% of the time. This will be solved by removing the package. >> -> there are Obsoletes after running tests. here I think as this is only after running tests, we can defer >> to 1.3 and remove the test for obsoletes in 1.2 >> >> >> Besides that, there are a number of things that need to be done for 1.2, they are listed here: >> >> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage >> >> 1.2 can only be released if this list is empty. >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |