خ ــادم الإسلام
12-02-2010, 07:26 مساءً
بسم الله الرحمن الرحيم
السلام عليكم اعضاء المرسى الكرام
نقلاً عن الشركة الأم
there has been a further delay to the release of 4.0.2 and we felt an explanation to our customers for this delay is in order. Ultimately the release dates are almost always an estimate and we do our best based on the information and resources we have at the time of when we’ll be done with the current fixes. However, continuous improvement is something we constantly strive for and, as a result, we are currently re-evaluating our process to make it better. Even the best process will sometimes force us to make hard decisions between meeting schedules and meeting the product goals. We feel that in this case taking the time to get this right is more important than any artificial timeline. We are sorry for any inconvenience this causes, but we believe the end result will be much better and the time well spent.
The process we follow for a maintenance release is that we first prioritize outstanding bugs, then the development team implements a number of fixes for these most critical ones. After this, we split the code off for testing and stabilization (which is why you see bugs fixed for 4.0.3 even though we haven't yet released 4.0.2). At this point only fixes deemed the most critical get merged into the prospective release – generally ones most important to customers – to fix things broken due to conflicts, or to complete previous fixes that weren't quite done correctly. Once we have the build stabilized, the qa team does a final pass through the release to check for problems.
So why a further delay for 4.0.2? To start with, we went over the estimate of fixes that we initially gave to qa -- more fixes means more time to test. We also identified a number of bugs fairly late in the process that we decided had to get fixed for 4.0.2, particularly those around rtl issues (right-to-left languages) and related to ie browser. We knew this would cause a delay, but we decided it was in the best interests of our customers to resolve these problems now rather than push them down to a future release.
Once we started digging into those bugs, we quickly found that fixing several of them would require very substantial changes to how we are handling rtl in ie6 and ie7. This required going through nearly all of the css in the system to find all the places that needed to be fixed. The trouble with changes like this is that it’s hard to estimate the time it will take to do the work. It also requires substantially more testing than we generally see with more focused fixes. Nonetheless, we felt what we could get done was of enough benefit to a significant number of customers that it was worth the risk to the schedule. So we went ahead with the fixes. As a consequence, our schedule became unpredictable and we've had to revise our release dates a couple of times as a result.
We hope you understand and we appreciate your patience while we make the new release the best we can before releasing it.
Kevin
بالعربيه
كان هناك مزيد من التأخير في اطلاق سراح 4.0.2 وشعرنا تفسيرا لعملائنا في هذا التأخير هو في النظام. في نهاية المطاف على الافراج عن مواعيد هي دائما تقريبا على تقدير ، ونحن نبذل قصارى جهدنا استنادا إلى المعلومات والموارد لدينا في وقت عندما نكون في عمله مع الإصلاحات الحالية. ومع ذلك ، والتحسين المستمر هو شيء ونحن نسعى باستمرار ل، ونتيجة لذلك ، نحن في صدد إعادة تقييم عمليتنا لجعله أفضل. حتى أفضل أحيانا العملية سوف تضطرنا إلى اتخاذ قرارات صعبة بين جداول الاجتماعات وتلبية أهداف المنتج. فإننا نرى أنه في هذه الحالة أخذ الوقت الكافي للحصول على هذا الحق هو أكثر أهمية من أي جدول زمني مصطنع. ونحن نعتذر عن أي إزعاج هذه الأسباب ، ولكننا نعتقد أن النتيجة النهائية ستكون أفضل بكثير وقتا ضائعا.
ونحن نتبع لعملية الحفاظ على الافراج عنهم هو أننا أول أولويات البق المعلقة ، ثم فريق التنمية تنفذ عددا من الحلول لهذه أكثرها حرجة. بعد هذا ، علينا تقسيم قبالة رمز للاختبار والاستقرار (والذي هو السبب في أننا نرى الخلل ثابتة ل4.0.3 حتى ولو لم نتوصل بعد الى الافراج 4.0.2). عند هذه النقطة فقط على الإصلاحات التي تعتبر حاسمة في الحصول على معظم دمجها في الافراج المحتملين -- عموما أهم العملاء -- لاصلاح الامور كسر نتيجة للصراعات ، أو لإكمال الإصلاحات السابقة التي لم يتم بشكل صحيح تماما. بعد أن نكون قد استقرت في بناء وفريق ضمان الجودة لا تمريرة النهائي ، من خلال إطلاق للتحقق من المشاكل.
فلماذا لمزيد من التأخير ل4.0.2؟ في البداية ، ذهبنا أكثر من تقدير للإصلاحات التي نحن في البداية أعطى لسؤال وجواب -- المزيد من الإصلاحات يعني المزيد من الوقت لاختبار. علينا أيضا أن عددا من الأخطاء في وقت متأخر نوعا ما في العملية التي قررنا زيارتها للحصول على ل4.0.2 ثابتة ، ولا سيما حول القضايا ار تى ال (من اليمين إلى اليسار لغات) والمتصلة آي إي للمتصفح. كنا نعرف هذا من شأنه أن يتسبب في تأخير ، ولكن قررنا انه كان في مصلحة عملائنا في حل هذه المشاكل الآن بدلا من دفعهم إلى أسفل إلى إصدار المستقبل.
مرة بدأنا الحفر في تلك البق ، وسرعان ما وجدنا أن تحديد العديد منهم سوف يتطلب تغييرات كبيرة جدا على الطريقة التي يتم التعامل ار تي ال في ie6 و ie7. هذا يتطلب المرور عبر ما يقرب من جميع من في النظام المغلق للعثور على جميع الأماكن التي تحتاج إلى أن تكون ثابتة. متاعب مع مثل هذه التغيرات هو أنه من الصعب تقدير الوقت الذي ستستغرقه للقيام بهذا العمل. كما أنه يتطلب أكثر بكثير من التجارب عموما نحن نرى مع أكثر تركيزا التصحيحات. ومع ذلك ، شعرنا ما يمكننا القيام به هو الحصول على فائدة كافية لعدد كبير من العملاء أنه كان يستحق المخاطرة على الجدول الزمني. فذهبنا قدما في الإصلاحات. ونتيجة لذلك ، أصبح لدينا جدول زمني لا يمكن التنبؤ بها ، وكان علينا أن نعيد النظر في مواعيد الافراج عن بضع مرات نتيجة لذلك.
ونأمل لكم فهم ، ونحن نقدر صبرك حتى يمكننا أن نجعل من الإصدار الجديد أفضل ما يمكن قبل إعلانها.
كيفين
ونسأل الله ان يوفقنا لما فيه الخير :15:
السلام عليكم اعضاء المرسى الكرام
نقلاً عن الشركة الأم
there has been a further delay to the release of 4.0.2 and we felt an explanation to our customers for this delay is in order. Ultimately the release dates are almost always an estimate and we do our best based on the information and resources we have at the time of when we’ll be done with the current fixes. However, continuous improvement is something we constantly strive for and, as a result, we are currently re-evaluating our process to make it better. Even the best process will sometimes force us to make hard decisions between meeting schedules and meeting the product goals. We feel that in this case taking the time to get this right is more important than any artificial timeline. We are sorry for any inconvenience this causes, but we believe the end result will be much better and the time well spent.
The process we follow for a maintenance release is that we first prioritize outstanding bugs, then the development team implements a number of fixes for these most critical ones. After this, we split the code off for testing and stabilization (which is why you see bugs fixed for 4.0.3 even though we haven't yet released 4.0.2). At this point only fixes deemed the most critical get merged into the prospective release – generally ones most important to customers – to fix things broken due to conflicts, or to complete previous fixes that weren't quite done correctly. Once we have the build stabilized, the qa team does a final pass through the release to check for problems.
So why a further delay for 4.0.2? To start with, we went over the estimate of fixes that we initially gave to qa -- more fixes means more time to test. We also identified a number of bugs fairly late in the process that we decided had to get fixed for 4.0.2, particularly those around rtl issues (right-to-left languages) and related to ie browser. We knew this would cause a delay, but we decided it was in the best interests of our customers to resolve these problems now rather than push them down to a future release.
Once we started digging into those bugs, we quickly found that fixing several of them would require very substantial changes to how we are handling rtl in ie6 and ie7. This required going through nearly all of the css in the system to find all the places that needed to be fixed. The trouble with changes like this is that it’s hard to estimate the time it will take to do the work. It also requires substantially more testing than we generally see with more focused fixes. Nonetheless, we felt what we could get done was of enough benefit to a significant number of customers that it was worth the risk to the schedule. So we went ahead with the fixes. As a consequence, our schedule became unpredictable and we've had to revise our release dates a couple of times as a result.
We hope you understand and we appreciate your patience while we make the new release the best we can before releasing it.
Kevin
بالعربيه
كان هناك مزيد من التأخير في اطلاق سراح 4.0.2 وشعرنا تفسيرا لعملائنا في هذا التأخير هو في النظام. في نهاية المطاف على الافراج عن مواعيد هي دائما تقريبا على تقدير ، ونحن نبذل قصارى جهدنا استنادا إلى المعلومات والموارد لدينا في وقت عندما نكون في عمله مع الإصلاحات الحالية. ومع ذلك ، والتحسين المستمر هو شيء ونحن نسعى باستمرار ل، ونتيجة لذلك ، نحن في صدد إعادة تقييم عمليتنا لجعله أفضل. حتى أفضل أحيانا العملية سوف تضطرنا إلى اتخاذ قرارات صعبة بين جداول الاجتماعات وتلبية أهداف المنتج. فإننا نرى أنه في هذه الحالة أخذ الوقت الكافي للحصول على هذا الحق هو أكثر أهمية من أي جدول زمني مصطنع. ونحن نعتذر عن أي إزعاج هذه الأسباب ، ولكننا نعتقد أن النتيجة النهائية ستكون أفضل بكثير وقتا ضائعا.
ونحن نتبع لعملية الحفاظ على الافراج عنهم هو أننا أول أولويات البق المعلقة ، ثم فريق التنمية تنفذ عددا من الحلول لهذه أكثرها حرجة. بعد هذا ، علينا تقسيم قبالة رمز للاختبار والاستقرار (والذي هو السبب في أننا نرى الخلل ثابتة ل4.0.3 حتى ولو لم نتوصل بعد الى الافراج 4.0.2). عند هذه النقطة فقط على الإصلاحات التي تعتبر حاسمة في الحصول على معظم دمجها في الافراج المحتملين -- عموما أهم العملاء -- لاصلاح الامور كسر نتيجة للصراعات ، أو لإكمال الإصلاحات السابقة التي لم يتم بشكل صحيح تماما. بعد أن نكون قد استقرت في بناء وفريق ضمان الجودة لا تمريرة النهائي ، من خلال إطلاق للتحقق من المشاكل.
فلماذا لمزيد من التأخير ل4.0.2؟ في البداية ، ذهبنا أكثر من تقدير للإصلاحات التي نحن في البداية أعطى لسؤال وجواب -- المزيد من الإصلاحات يعني المزيد من الوقت لاختبار. علينا أيضا أن عددا من الأخطاء في وقت متأخر نوعا ما في العملية التي قررنا زيارتها للحصول على ل4.0.2 ثابتة ، ولا سيما حول القضايا ار تى ال (من اليمين إلى اليسار لغات) والمتصلة آي إي للمتصفح. كنا نعرف هذا من شأنه أن يتسبب في تأخير ، ولكن قررنا انه كان في مصلحة عملائنا في حل هذه المشاكل الآن بدلا من دفعهم إلى أسفل إلى إصدار المستقبل.
مرة بدأنا الحفر في تلك البق ، وسرعان ما وجدنا أن تحديد العديد منهم سوف يتطلب تغييرات كبيرة جدا على الطريقة التي يتم التعامل ار تي ال في ie6 و ie7. هذا يتطلب المرور عبر ما يقرب من جميع من في النظام المغلق للعثور على جميع الأماكن التي تحتاج إلى أن تكون ثابتة. متاعب مع مثل هذه التغيرات هو أنه من الصعب تقدير الوقت الذي ستستغرقه للقيام بهذا العمل. كما أنه يتطلب أكثر بكثير من التجارب عموما نحن نرى مع أكثر تركيزا التصحيحات. ومع ذلك ، شعرنا ما يمكننا القيام به هو الحصول على فائدة كافية لعدد كبير من العملاء أنه كان يستحق المخاطرة على الجدول الزمني. فذهبنا قدما في الإصلاحات. ونتيجة لذلك ، أصبح لدينا جدول زمني لا يمكن التنبؤ بها ، وكان علينا أن نعيد النظر في مواعيد الافراج عن بضع مرات نتيجة لذلك.
ونأمل لكم فهم ، ونحن نقدر صبرك حتى يمكننا أن نجعل من الإصدار الجديد أفضل ما يمكن قبل إعلانها.
كيفين
ونسأل الله ان يوفقنا لما فيه الخير :15: