Actions done in 1.3
Locked
 
|
Hi guys
to help us in the future I started http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree The list starts to get long... Stef |
|
|
On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote: > Hi guys > > to help us in the future I started > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree > > The list starts to get long... Maybe we should do a 1.3 release soon... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: Actions done in 1.3
|
|
Yes!!! totally agree. Now that we release 1.2, I would freeze and release PharoCore 1.3 beta. Update the link to stable pharo to that, and start trying to load the dev tools there.
Cheers Mariano
On Tue, Apr 5, 2011 at 10:39 PM, Marcus Denker <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
|
|
On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck <[hidden email]> wrote: Yes!!! totally agree. Now that we release 1.2, I would freeze and release PharoCore 1.3 beta. Update the link to stable pharo to that, and start trying to load the dev tools there.
+10
And propose a fixed date for release - no compromise, will be release at this date. Laurent.
|
|
|
ok for me.
Stef > On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck <[hidden email]> wrote: > Yes!!! totally agree. Now that we release 1.2, I would freeze and release PharoCore 1.3 beta. Update the link to stable pharo to that, and start trying to load the dev tools there. > > +10 > > And propose a fixed date for release - no compromise, will be release at this date. > > Laurent. > > > Cheers > > Mariano > > > On Tue, Apr 5, 2011 at 10:39 PM, Marcus Denker <[hidden email]> wrote: > > On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote: > > > Hi guys > > > > to help us in the future I started > > > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree > > > > The list starts to get long... > > Maybe we should do a 1.3 release soon... > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > |
|
|
In reply to this post by laurent laffont
On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont
<[hidden email]> wrote: > On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck > <[hidden email]> wrote: >> >> Yes!!! totally agree. Now that we release 1.2, I would freeze and release >> PharoCore 1.3 beta. Update the link to stable pharo to that, and start >> trying to load the dev tools there. > > +10 > And propose a fixed date for release - no compromise, will be release at > this date. +1 Timeboxing sounds great. Podomoro for software development ;-) Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ |
|
|
Planning is also important.
Time is good, but another thing is i think we should think about, what features we want to be in new release, and do not release until they delivered. Besides bug fixing and minor improvements, there should be some functionality which we want to have in new release, so then you could say: 1.x is better than previous because of A,B,C, but not because a,b,c ( capital letters is major stuff, while regular ones is for minor stuff ) :) On 6 April 2011 10:01, Serge Stinckwich <[hidden email]> wrote: > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont > <[hidden email]> wrote: >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck >> <[hidden email]> wrote: >>> >>> Yes!!! totally agree. Now that we release 1.2, I would freeze and release >>> PharoCore 1.3 beta. Update the link to stable pharo to that, and start >>> trying to load the dev tools there. >> >> +10 >> And propose a fixed date for release - no compromise, will be release at >> this date. > > +1 > Timeboxing sounds great. > Podomoro for software development ;-) > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Best regards, Igor Stasenko AKA sig. |
|
|
On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <[hidden email]> wrote: Planning is also important. I don't really like this. I prefer rhythm, agility. Timeboxing enables maximum value in each release. If a feature is really important, it will be on time. If not on time, it means it was no so important.
Always green test is a must-have. Besides bug fixing and minor improvements, there should be some That should be a goal, but don't delay a release because the feature is not here. If releases are often ( for example every 3 months), shorter, it won't be a big problem to wait for the next one.
I prefer to have a release *now* without my feature and wait 3 months for the next release than no release and waiting for 3 months more with less and less energy.
Laurent. so then you could say: 1.x is better than previous because of A,B,C, |
|
|
---------- Forwarded message ----------
From: Igor Stasenko <[hidden email]> Date: 6 April 2011 13:55 Subject: Re: [Pharo-project] Actions done in 1.3 To: laurent laffont <[hidden email]> On 6 April 2011 10:30, laurent laffont <[hidden email]> wrote: > > On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <[hidden email]> wrote: >> >> Planning is also important. >> >> Time is good, but another thing is i think we should think about, >> what features we want to be in new release, and do not release until >> they delivered. > > I don't really like this. I prefer rhythm, agility. Timeboxing enables > maximum value in each release. If a feature is really important, it will be > on time. If not on time, it means it was no so important. > Always green test is a must-have. > >> >> Besides bug fixing and minor improvements, there should be some >> functionality which we want to have in new release, > > That should be a goal, but don't delay a release because the feature is not > here. If releases are often ( for example every 3 months), shorter, it won't > be a big problem to wait for the next one. > I prefer to have a release *now* without my feature and wait 3 months for > the next release than no release and waiting for 3 months more with less and > less energy. > But you don't have to wait, if you want to stay on bleeding edge, you know how to do that. Just go to hudson and dowload freshly built 1.3 image. Because if you can pick any image at any moment and declare it new release, then i don't understand why do we need releases at all? What makes release to be release , when you can download latest version at any moment? That's why i saying that from release to release cleanup and fixes is good, but there should be some major functional changes, which worth to be labeled as a new version. And if you don't have them, then there is no point to make a release. > Laurent. > -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig. |
|
|
On Wed, Apr 6, 2011 at 1:55 PM, Igor Stasenko <[hidden email]> wrote:
I won't do this for production. We need a officially released image.
Because people build applications / frameworks they declare compatible with a fixed version of Pharo.
The date :) Ubuntu is released every 6 months. That gives a rhythm. Integrates new stuff, freeze, release.
Same for Gnome and KDE. Linux kernel has a 2 weeks merge window then go rc. We have learned the benefits of fixed iteration with agile methods & extreme programming.
In three months there's a lot of stuff which enters Pharo. That's enough for me to justify a release and get feedback from users.
Laurent.
|
|
|
In reply to this post by laurent laffont
On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <[hidden email]> wrote:
I couldn't disagree more. Especially with VisualWorks time-boxing has caused problems with quality and delivery of functionality. Fundamentally there is no point putting out a release for the sake of it. A release is about functionality, both new functionality and bug fixes. Without either of these there is absolutely no point in releasing anything beyond marketing. Yes, during a release one can make the call that because a subset of the functionality will arrive much later than the rest of the functionality it makes sense for that late functionality to slip the release and arrive in a later one. But that doesn't imply putting out an essentially empty release for the sake of promptness.
One thing I do approve of is maintennance releases, where some time after an initial release one puts out a maintennance release that only contains bug fixes and no new functionality and I think there are good arguments for and positive experience with scheduling the maintennance release to arrive at some fixed time after the first release, e.g. 4 to 6 months. But major releases must IMO be driven by content.
best Eliot
|
|
|
Em 06-04-2011 17:32, Eliot Miranda escreveu:
+1 Here +1 Here but... I think that maintenance releases must be presented in the form of "software updates" (meaning, no need to install a new image & reinstall everything in it). Ideally it should be possible to upgrade fixes without breaking what's working. Best regards, CdAB |
|
|
In reply to this post by Eliot Miranda-2
On 6 April 2011 22:32, Eliot Miranda <[hidden email]> wrote:
> > > On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <[hidden email]> > wrote: >> >> On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <[hidden email]> wrote: >>> >>> Planning is also important. >>> >>> Time is good, but another thing is i think we should think about, >>> what features we want to be in new release, and do not release until >>> they delivered. >> >> I don't really like this. I prefer rhythm, agility. Timeboxing enables >> maximum value in each release. If a feature is really important, it will be >> on time. If not on time, it means it was no so important. > > I couldn't disagree more. Especially with VisualWorks time-boxing has > caused problems with quality and delivery of functionality. Fundamentally > there is no point putting out a release for the sake of it. A release is > about functionality, both new functionality and bug fixes. Without either > of these there is absolutely no point in releasing anything beyond > marketing. Yes, during a release one can make the call that because a > subset of the functionality will arrive much later than the rest of the > functionality it makes sense for that late functionality to slip the release > and arrive in a later one. But that doesn't imply putting out an > essentially empty release for the sake of promptness. > One thing I do approve of is maintennance releases, where some time after an > initial release one puts out a maintennance release that only contains bug > fixes and no new functionality and I think there are good arguments for and > positive experience with scheduling the maintennance release to arrive at > some fixed time after the first release, e.g. 4 to 6 months. But major > releases must IMO be driven by content. Right. That's exactly what i wanted to say. There's no point to make a release of a 'new version' if it doesn't contains a functionality which were planned to include. Maintenance is sufficient for this. -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by CdAB63
On Wed, Apr 6, 2011 at 1:52 PM, Casimiro de Almeida Barreto <[hidden email]> wrote:
Agreed. What I said about maintennance releases was rather 20th century of me. Forget I ever mentioned it :)
|
|
|
I do not have specific stance on that this is why I hear both arguments.
Now agility is not something that we claim but that we do. I think that not having releases that drag on forever is important. I prefer to have - 3/4 releases full of energy that are time based vs. 2 that are slugglish and ends up in few fixes over a long period. - this would avoid to have an accumulation of code to integrate and laucnh beta too early to reduce the pressure. - In addition since people do not understand what is a release candidate, then having more frequent release would mean that people port more often if they want. So we will see. For now the good point is that we can release 1.3 tomorrow and this will not be a release maintenance because lot of changes are already done. Stef On Apr 6, 2011, at 11:40 PM, Eliot Miranda wrote: > > > On Wed, Apr 6, 2011 at 1:52 PM, Casimiro de Almeida Barreto <[hidden email]> wrote: > Em 06-04-2011 17:32, Eliot Miranda escreveu: >> >> >> >> (...) >> >> >> I couldn't disagree more. Especially with VisualWorks time-boxing has caused problems with quality and delivery of functionality. Fundamentally there is no point putting out a release for the sake of it. A release is about functionality, both new functionality and bug fixes. Without either of these there is absolutely no point in releasing anything beyond marketing. Yes, during a release one can make the call that because a subset of the functionality will arrive much later than the rest of the functionality it makes sense for that late functionality to slip the release and arrive in a later one. But that doesn't imply putting out an essentially empty release for the sake of promptness. > +1 Here > >> >> One thing I do approve of is maintennance releases, where some time after an initial release one puts out a maintennance release that only contains bug fixes and no new functionality and I think there are good arguments for and positive experience with scheduling the maintennance release to arrive at some fixed time after the first release, e.g. 4 to 6 months. But major releases must IMO be driven by content. > +1 Here but... > > I think that maintenance releases must be presented in the form of "software updates" (meaning, no need to install a new image & reinstall everything in it). Ideally it should be possible to upgrade fixes without breaking what's working. > > Agreed. What I said about maintennance releases was rather 20th century of me. Forget I ever mentioned it :) > >> >> best >> Eliot >> >> (...) >> > Best regards, > > CdAB > |
|
|
In reply to this post by Eliot Miranda-2
On Apr 7, 2011, at 9:17 AM, Stéphane Ducasse wrote: > I do not have specific stance on that this is why I hear both arguments. > > Now agility is not something that we claim but that we do. > I think that not having releases that drag on forever is important. > I prefer to have > - 3/4 releases full of energy that are time based vs. 2 that are slugglish and ends up in few fixes over a long period. > - this would avoid to have an accumulation of code to integrate and laucnh beta too early to reduce the pressure. > - In addition since people do not understand what is a release candidate, then having more frequent release would mean > that people port more often if they want. > So we will see. For now the good point is that we can release 1.3 tomorrow and this will not be a release maintenance because > lot of changes are already done. > The next steps are: -> go over the bug tracker and tag as 1.3 just the real important entries -> Fix the easy to fix failing tests (just 25 to go) -> Do another iteration on the build server for complete auto-build to the artififact we ship. and: -> Do another iteration on Cog builds so we can move to Cog only. I want a 1.3 that is in "we could release today if we wanted" 90% of the time. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
On 7 avr. 2011, at 09:53, Marcus Denker wrote: > > I want a 1.3 that is in "we could release today if we wanted" 90% of the time. > > Yes! What about integrating only things that do not break tests? I mean : -have a DEV version with all what we want -having a "STABLE" version where all tests are green. Fixes/extensions are migrated from the to STABLE each time the DEV tests go green. The lifecycle would be a sequence of iterations. Each iteration would be similar to something like what Laurent suggested: -Additions to DEV (fixes/enhancements/whatever) -Fixing DEV -Committing to STABLE Noury http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |