4.1 release timing
Locked
12
12
 
|
On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <[hidden email]> wrote:
> In my experience it is almost always better to think things through and fix known issues instead of rushing for some arbitrary deadline. I think this depends on our goals. I would like to see us aiming for continuous improvement rather than instant perfection at some distant time in the future. And my understanding of continuous improvement also includes more frequent releases. Rebasing the trunk tree on 4.0 makes an excellent goal for me and would justify a 0.1 incremented release. > Do it right the first time. This would make having sex a misión imposible ;) Alex |
|
In reply to this post by Ken G. Brown
On Mar 17, 2010, at 11:36 AM, Ken G. Brown wrote: > At 11:13 AM -0700 3/17/10, Randal L. Schwartz apparently wrote: >>>>>>> "Ken" == Ken G Brown <[hidden email]> writes: >> >> Ken> In my experience it is almost always better to think things through and >> Ken> fix known issues instead of rushing for some arbitrary deadline. It is >> Ken> always better to fix things before they are released. Do it right the >> Ken> first time. >> >> And I don't think anyone is disagreeing with that. But that's too abstract to >> have a game plan. >> >> If we feature-freeze 4.1, say, next monday, there's not a lot of reasons >> why everything couldn't get greenlighted within a few weeks after that. >> Might not make it, but it's a reasonable goal. >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > > Ok, I could see publishing the game plan, including all tests green, agree to the game plan then work towards it. I'm pretty sure that's what everyone is voting +1 to. > > But for sure, don't push it out if the feature set is not met just to meet some arbitrary deadline. > That's what it is sounding like will happen. > I didn't hear it that way at all, and it sounds like Randal didn't either. Looking back at the original message, I now see it wasn't explicit about this, so I can see how confusion could happen (even though it was perfectly clear to me that it was the "smart" thing being proposed, not the "stupid" thing that you assumed). May I gently suggest that your default reaction to anything said by (loosely speaking) the SOB is perhaps overly pessimistic? Cheers, Josh > Ken G. Brown > |
|
|
In reply to this post by Bert Freudenberg
On Wed, Mar 17, 2010 at 5:30 PM, Bert Freudenberg <[hidden email]> wrote:
> On 17.03.2010, at 17:15, Randal L. Schwartz wrote: >> >>>>>>> "Andreas" == Andreas Raab <[hidden email]> writes: >> >> Andreas> Would you prefer a very quick 4.1 release (4 weeks max) that *just* >> Andreas> packages up the current trunk state (no extra packages in order to >> Andreas> save time) or would you prefer that we take some time now discuss >> Andreas> this through before 4.1? >> >> I'd be happy with a quick 4.1 release that represent's a year's improvement >> on 4.0, and then take another year to really think out and develop 4.2. > > +1 to a quick 4.1 release. Let's keep 4.2 out of the discussion for now. > > - Bert - > > > > 4.1 isen't that 1 april ? :-) Karl |
|
|
In reply to this post by laza
On 2010-03-17, at 12:52 PM, Alexander Lazarević <[hidden email]> wrote: > On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <[hidden email]> wrote: >> In my experience it is almost always better to think things through >> and fix known issues instead of rushing for some arbitrary deadline. > > I think this depends on our goals. I would like to see us aiming for > continuous improvement rather than instant perfection at some distant > time in the future. And my understanding of continuous improvement > also includes more frequent releases. > Rebasing the trunk tree on 4.0 makes an excellent goal for me and > would justify a 0.1 incremented release. > >> Do it right the first time. > > This would make having sex a misión imposible ;) > > Alex > You've got a good point there! :) However I see that perhaps generalisims don't always apply. I am referring to the conclusions that HP came up with years ago when they studied why the Japanese manufacturing seemed to be doing so well. They evidently sent a team over to study Japanese management techniques. After some time they discovered that they appeared to strive for incremental improvement, and if they discovered a defect, say in an electronic board, they would take the time to not only correct the defect, but also fix the underlying cause of the defect, always working towards the long term improvement of the processes, not the short term gain. US manufacturing tended towards the short term only. HP instituted quite a few of these improved concepts in their board manufacturing and as I recall saved something like $20 million the first year, just in reduced inventory of electronics waiting for testing. Their conclusion was 'do it right the first time' even if it makes the schedule slip. If you know there is something wrong, take the time to fix. Anyone interested can grab some of the well known books on Japanese Manufacturing for some good concepts. And I've personally had to deal with fixing things on customer sites that were rushed out unfinished to meet an arbitrary deadline. It's very expensive and embarassing to say the least. Let's not rush 4.1 out to try to cover the shortfalls caused by rushing 4.0 out with fanfare even before the deal is signed and sealed. Ken G. Brown from my iPhone |
|
|
On 17.03.2010, at 21:03, Ken G. Brown wrote:
> > > > > > On 2010-03-17, at 12:52 PM, Alexander Lazarević <[hidden email]> wrote: > >> On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <[hidden email]> wrote: >>> In my experience it is almost always better to think things through and fix known issues instead of rushing for some arbitrary deadline. >> >> I think this depends on our goals. I would like to see us aiming for >> continuous improvement rather than instant perfection at some distant >> time in the future. And my understanding of continuous improvement >> also includes more frequent releases. >> Rebasing the trunk tree on 4.0 makes an excellent goal for me and >> would justify a 0.1 incremented release. >> >>> Do it right the first time. >> >> This would make having sex a misión imposible ;) >> >> Alex >> > > You've got a good point there! :) > However I see that perhaps generalisims don't always apply. > > I am referring to the conclusions that HP came up with years ago when they studied why the Japanese manufacturing seemed to be doing so well. They evidently sent a team over to study Japanese management techniques. After some time they discovered that they appeared to strive for incremental improvement, and if they discovered a defect, say in an electronic board, they would take the time to not only correct the defect, but also fix the underlying cause of the defect, always working towards the long term improvement of the processes, not the short term gain. US manufacturing tended towards the short term only. > HP instituted quite a few of these improved concepts in their board manufacturing and as I recall saved something like $20 million the first year, just in reduced inventory of electronics waiting for testing. > > Their conclusion was 'do it right the first time' even if it makes the schedule slip. If you know there is something wrong, take the time to fix. > > Anyone interested can grab some of the well known books on Japanese Manufacturing for some good concepts. > > And I've personally had to deal with fixing things on customer sites that were rushed out unfinished to meet an arbitrary deadline. It's very expensive and embarassing to say the least. > > Let's not rush 4.1 out to try to cover the shortfalls caused by rushing 4.0 out with fanfare even before the deal is signed and sealed. > > Ken G. Brown That all good and true when you develop a product. In a volunteer-driven open-source project the mantra is "release early, release often". If we can get into a steady release rhythm then there is no need to hold one release for a particular feature, because the next one is right around the corner. So, propose the blockers to 4.1 now. The release manager will decide if it's worth holding the release for them or not. We don't want to "rush" this release by ignoring those blockers, but we want it out swiftly on the heels of 4.0. - Bert - |
|
|
In reply to this post by Ken G. Brown
Hi Ken,
Send a copy of that book to Toyota. :) Sorry couldn't resist. Ron > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Ken G. Brown > Sent: Wednesday, March 17, 2010 4:04 PM > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] 4.1 release timing > > > > > > On 2010-03-17, at 12:52 PM, Alexander Lazarević <[hidden email]> > wrote: > > > On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <[hidden email]> wrote: > >> In my experience it is almost always better to think things through > >> and fix known issues instead of rushing for some arbitrary deadline. > > > > I think this depends on our goals. I would like to see us aiming for > > continuous improvement rather than instant perfection at some distant > > time in the future. And my understanding of continuous improvement > > also includes more frequent releases. > > Rebasing the trunk tree on 4.0 makes an excellent goal for me and > > would justify a 0.1 incremented release. > > > >> Do it right the first time. > > > > This would make having sex a misión imposible ;) > > > > Alex > > > > You've got a good point there! :) > However I see that perhaps generalisims don't always apply. > > I am referring to the conclusions that HP came up with years ago when > they studied why the Japanese manufacturing seemed to be doing so > well. They evidently sent a team over to study Japanese management > techniques. After some time they discovered that they appeared to > strive for incremental improvement, and if they discovered a defect, > say in an electronic board, they would take the time to not only > correct the defect, but also fix the underlying cause of the defect, > always working towards the long term improvement of the processes, not > the short term gain. US manufacturing tended towards the short term > only. > HP instituted quite a few of these improved concepts in their board > manufacturing and as I recall saved something like $20 million the > first year, just in reduced inventory of electronics waiting for > testing. > > Their conclusion was 'do it right the first time' even if it makes the > schedule slip. If you know there is something wrong, take the time to > fix. > > Anyone interested can grab some of the well known books on Japanese > Manufacturing for some good concepts. > > And I've personally had to deal with fixing things on customer sites > that were rushed out unfinished to meet an arbitrary deadline. It's > very expensive and embarassing to say the least. > > Let's not rush 4.1 out to try to cover the shortfalls caused by > rushing 4.0 out with fanfare even before the deal is signed and sealed. > > Ken G. Brown > from my iPhone |
|
|
In reply to this post by Bert Freudenberg
On Wed, Mar 17, 2010 at 1:21 PM, Bert Freudenberg <[hidden email]> wrote:
+1 x 3
|
|
|
In reply to this post by Andreas.Raab
Folks -
Catching up with email today it seems that there's a *much* stronger preference for a quick 4.1 release than I had imagined. I thought it an issue worth raising but didn't expect that clear a response in favor of a quick 4.1. As a consequence, I think we should adjust our plans accordingly. However, this may create a bit of a dilemma: I don't think that Edgar signed up for these conditions, and I'm not sure if it's fair to push it on him - making a release in a short time frame takes a lot of work and I don't want to just drop this into Edgar's lap given that I have no idea about his availability and other schedules. So here's what I'll do: I'll send another message with proper subject to gather tasks that need to be addressed to get 4.1 out. Edgar, if you then still feel this is the release you want to manage (or simply participate) let us know. Cheers, - Andreas On 3/17/2010 8:59 AM, Andreas Raab wrote: > Folks - > > Now that 4.0 is out it's clear that the next version will be 4.1. One > thing that I've noticed is that various people (both on and offlist) > have pointed out that it may be good if we'd release 4.1 ASAP in order > to both, minimize confusion (i.e., "4.0 is like 3.10") as well as keep > up momentum (i.e., make submissions for 4.0 and 4.1 on news sites). > > Originally, I had hoped that we'd take a bit of time to talk about what > packages, documentation, and apps to package into 4.1 but doing that > does take time (we haven't even started the discussion yet) and would > make it impossible to do a very quick 4.1 release. I'm open either way > but I'm curious what the community thinks: > > Would you prefer a very quick 4.1 release (4 weeks max) that *just* > packages up the current trunk state (no extra packages in order to save > time) or would you prefer that we take some time now discuss this > through before 4.1? > > Personally, I'm good either way; anything that won't be getting done > this round will be in the next, but I think pepping the release up a bit > would be good, too :-) So I'm curious what the community thinks. > > Cheers, > - Andreas > > > |
|
|
>>>>> "Andreas" == Andreas Raab <[hidden email]> writes:
Andreas> So here's what I'll do: I'll send another message with proper subject Andreas> to gather tasks that need to be addressed to get 4.1 out. Edgar, if Andreas> you then still feel this is the release you want to manage (or simply Andreas> participate) let us know. I think this is wise, given that you and I are now 2010 board members. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |