Re: Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Petr Mladek píše v Po 03. 09. 2012 v 18:41 +0200: 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. After all, this is still good solution. We released, 3.5 and 3.6 this way and it somehow worked. The .0 release is always hectic and we get many fixes every week, so the two weeks delay between rc2 and rc3 would be too long. After all we used something close to this. The schedule is: + Week 2: 3.7.0-rc1 + Week 3: + Week 4: 3.7.0-rc2 + Week 5: 3.7.0-rc3 + Week 6: 3.7.0-release + Week 7: + Week 8: 3.7.1-rc1 + Week 9: 3.7.1-rc2 + Week 10: 3.7.1-release + Week 11: 3.7.2-rc1 + Week 12: + Week 13: 3.7.2-rc2 + Week 14: 3.7.2-release + Week 15: 3.7.3-rc1 + Week 16: + Week 17: 3.7.4-rc2 + Week 18: 3.7.4-release By other words, I moved 3.7.0-rc3 and 3.7.1.rc1 and created space between them. It is not ideal but we will do it better in the future releases. See also https://wiki.documentfoundation.org/ReleasePlan Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Bjoern Michaelsen píše v Čt 30. 08. 2012 v 17:41 +0200: On Thu, Aug 30, 2012 at 05:14:02PM +0200, Petr Mladek wrote: As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Comparing: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule http://wiki.documentfoundation.org/ReleasePlan/3.7 I find currently: - the 3.7.0 is already too late for a Alpha1/FeatureFreeze Well, the LO feature freeze is already for beta1 in December. The hard code freeze is three weeks before the .0 release. I guess that 3.6.0-rc2 would be fine for Ubuntu alpha1. - the 3.7.1 is already currently is ok for the BetaFreeze (LibreOffice is seeded) - the 3.7.2 release is fitting in just before Final Freeze I see. OK, we can't move it later. - the 3.7.3 release is already a SRU (stable release update) Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. It might be possible. Let's discuss it on ESC call this week. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3.x.3 is already too late for us currently -- however, pushing back two weeks would make 3.7.2 miss final freeze. In that case I would have to seriously consider to not ship that series at all -- shipping with a 3.7.1 is very likely too early. This is no way. We do not want to break your release. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing Personally, that sounds like the best option for me for 3.7. I am not much happy with it because it could cause worse quality of .0 release. 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. After all, this is still good solution. We released, 3.5 and 3.6 this way and it somehow worked. The .0 release is always hectic and we get many fixes every week, so the two weeks delay between rc2 and rc3 would be too long. If ESC rejects moving the whole release two weeks earlier, I would go with tho 4th solution and do builds every week for 3.7.0 and 3.7.1 releases. Of course, I would shift the whole release in the future. Thanks for feedback. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Bjoern Michaelsen píše v Čt 30. 08. 2012 v 17:41 +0200: On Thu, Aug 30, 2012 at 05:14:02PM +0200, Petr Mladek wrote: As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Comparing: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule http://wiki.documentfoundation.org/ReleasePlan/3.7 I find currently: - the 3.7.0 is already too late for a Alpha1/FeatureFreeze Well, the LO feature freeze is already for beta1 in December. The hard code freeze is three weeks before the .0 release. I guess that 3.6.0-rc2 would be fine for Ubuntu alpha1. - the 3.7.1 is already currently is ok for the BetaFreeze (LibreOffice is seeded) - the 3.7.2 release is fitting in just before Final Freeze I see. OK, we can't move it later. - the 3.7.3 release is already a SRU (stable release update) Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. It might be possible. Let's discuss it on ESC call this week. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3.x.3 is already too late for us currently -- however, pushing back two weeks would make 3.7.2 miss final freeze. In that case I would have to seriously consider to not ship that series at all -- shipping with a 3.7.1 is very likely too early. This is no way. We do not want to break your release. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing Personally, that sounds like the best option for me for 3.7. I am not much happy with it because it could cause worse quality of .0 release. 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. After all, this is still good solution. We released, 3.5 and 3.6 this way and it somehow worked. The .0 release is always hectic and we get many fixes every week, so the two weeks delay between rc2 and rc3 would be too long. If ESC rejects moving the whole release two weeks earlier, I would go with tho 4th solution and do builds every week for 3.7.0 and 3.7.1 releases. Of course, I would shift the whole release in the future. Thanks for feedback. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Petr Mladek píše v Čt 30. 08. 2012 v 16:53 +0200: Hi, on the recent ESC call, we agreed to try two weeks between RCs. It will allow QA to do more testing. Also it will allow developers to fix the found regressions. Please, find the updated release plan at http://wiki.documentfoundation.org/ReleasePlan As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. I think that the 2nd solution is the best compromise for 3.7.0. The 1st variant would be best for the further releases (3.8.0, 3.9.0). Bjorn, Caolan, others, would you mind if we delay 3.7.X bugfix releases by 1 or 2 weeks? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
On Thu, Aug 30, 2012 at 05:14:02PM +0200, Petr Mladek wrote: As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Comparing: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule http://wiki.documentfoundation.org/ReleasePlan/3.7 I find currently: - the 3.7.0 is already too late for a Alpha1/FeatureFreeze - the 3.7.1 is already currently is ok for the BetaFreeze (LibreOffice is seeded) - the 3.7.2 release is fitting in just before Final Freeze - the 3.7.3 release is already a SRU (stable release update) Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. understood. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3.x.3 is already too late for us currently -- however, pushing back two weeks would make 3.7.2 miss final freeze. In that case I would have to seriously consider to not ship that series at all -- shipping with a 3.7.1 is very likely too early. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing Personally, that sounds like the best option for me for 3.7. 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. Yep. I think that the 2nd solution is the best compromise for 3.7.0. The 1st variant would be best for the further releases (3.8.0, 3.9.0). I would prefer to go with 3) for 3.7 and 1) for later releases (shifting at least two weeks). Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-qa] Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Petr Mladek píše v Čt 30. 08. 2012 v 16:53 +0200: Hi, on the recent ESC call, we agreed to try two weeks between RCs. It will allow QA to do more testing. Also it will allow developers to fix the found regressions. Please, find the updated release plan at http://wiki.documentfoundation.org/ReleasePlan As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. I think that the 2nd solution is the best compromise for 3.7.0. The 1st variant would be best for the further releases (3.8.0, 3.9.0). Bjorn, Caolan, others, would you mind if we delay 3.7.X bugfix releases by 1 or 2 weeks? Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
