<br><br><div class="gmail_quote">On Wed, Mar 17, 2010 at 1:21 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 17.03.2010, at 21:03, Ken G. Brown wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On 2010-03-17, at 12:52 PM, Alexander Lazarević <<a href="mailto:laza@blobworks.com">laza@blobworks.com</a>> wrote:<br>
><br>
>> On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <<a href="mailto:kbrown@mac.com">kbrown@mac.com</a>> wrote:<br>
>>> In my experience it is almost always better to think things through and fix known issues instead of rushing for some arbitrary deadline.<br>
>><br>
>> I think this depends on our goals. I would like to see us aiming for<br>
>> continuous improvement rather than instant perfection at some distant<br>
>> time in the future. And my understanding of continuous improvement<br>
>> also includes more frequent releases.<br>
>> Rebasing the trunk tree on 4.0 makes an excellent goal for me and<br>
>> would justify a 0.1 incremented release.<br>
>><br>
>>> Do it right the first time.<br>
>><br>
>> This would make having sex a misión imposible ;)<br>
>><br>
>> Alex<br>
>><br>
><br>
> You've got a good point there! :)<br>
> However I see that perhaps generalisims don't always apply.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> 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.<br>
><br>
> Anyone interested can grab some of the well known books on Japanese Manufacturing for some good concepts.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Ken G. Brown<br>
<br>
</div></div>That all good and true when you develop a product.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote><div><br></div><div>+1 x 3</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Bert -<br>
<br>
<br>
<br>
</font></blockquote></div><br>