[xwiki-devs] [proposal] Release 3.1-RC1 on scheduled release date.
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following: 1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it. 3. Release happens on Monday regardless of the state of the tests. Since the release date is upon us, I need a quick response on this. WDYT? Caleb
+1 Thanks, Marius On 05/26/2011 06:03 AM, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it. 3. Release happens on Monday regardless of the state of the tests.
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, 2011-05-25 at 23:03 -0400, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
I think these should be fixed, because they prove regressions (or are at least a warning for a regression). While I agree with timeboxing, I think this is slightly too much, as in we shouldn't push a release with regressions just because we were late with the milestones.
3. Release happens on Monday regardless of the state of the tests.
see above. Thanks, Anca
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 05/26/2011 04:25 AM, Luca Anca wrote:
On Wed, 2011-05-25 at 23:03 -0400, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
I think these should be fixed, because they prove regressions (or are at least a warning for a regression).
While I agree with timeboxing, I think this is slightly too much, as in we shouldn't push a release with regressions just because we were late with the milestones.
When do you propose to release? Caleb
3. Release happens on Monday regardless of the state of the tests.
see above.
Thanks, Anca
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, 2011-05-26 at 04:44 -0400, Caleb James DeLisle wrote:
On 05/26/2011 04:25 AM, Luca Anca wrote:
On Wed, 2011-05-25 at 23:03 -0400, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
I think these should be fixed, because they prove regressions (or are at least a warning for a regression).
While I agree with timeboxing, I think this is slightly too much, as in we shouldn't push a release with regressions just because we were late with the milestones.
When do you propose to release?
I'm not necessarily against the release date, I just don't think that this policy about tests is a good one. If we manage to have no tests failing on the build by Monday, Monday is fine. We can target Monday with an extension to, say, Thursday or next Monday if we need time to fix regressions. Unfortunately though, I'm not able to have a 1 on this proposal, be it a + or -, because I won't be able to spend time on the development of this cycle. Thanks, Anca
Caleb
3. Release happens on Monday regardless of the state of the tests.
see above.
Thanks, Anca
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, May 26, 2011 at 05:03, Caleb James DeLisle <[email protected]> wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability. 2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
Ok for flickering test but If what you are proposing is doing a release with known regressions it's a big -1 from me. I prefer reverting a commit that caused the regression, we can't release a new version and just don't care about regressions which is the worst thing possible IMO. It's not like we were talking about a milestone...
3. Release happens on Monday regardless of the state of the tests.
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Caleb, On May 26, 2011, at 5:03 AM, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability.
+1
2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
+1, we should also add a keyword so that we can easily filter them out (I propose "quarantined" or "flickering")
3. Release happens on Monday regardless of the state of the tests.
-1. For any failing test we must verify if the problem is a test issue or a real bug. If it's a real bug we need to analyze the criticity. If it's critical we shouldn't release without fixing it. If it's not critical then we can release but we'll need to add this information in the Release notes if it's a regression.
Since the release date is upon us, I need a quick response on this.
Thanks -Vincent
On 05/26/2011 06:06 AM, Vincent Massol wrote:
Hi Caleb,
On May 26, 2011, at 5:03 AM, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability.
+1
2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
+1, we should also add a keyword so that we can easily filter them out (I propose "quarantined" or "flickering")
3. Release happens on Monday regardless of the state of the tests.
-1. For any failing test we must verify if the problem is a test issue or a real bug. If it's a real bug we need to analyze the criticity. If it's critical we shouldn't release without fixing it. If it's not critical then we can release but we'll need to add this information in the Release notes if it's a regression.
I am happy to hold the release until you give the okay. I volunteer to get the storage tests running. Caleb
Since the release date is upon us, I need a quick response on this.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I follow Thomas and Vincent on this. We should not hustled the release just to be on schedule. Denis On Thu, May 26, 2011 at 14:44, Caleb James DeLisle <[email protected]
wrote:
On 05/26/2011 06:06 AM, Vincent Massol wrote:
Hi Caleb,
On May 26, 2011, at 5:03 AM, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability.
+1
2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
+1, we should also add a keyword so that we can easily filter them out (I propose "quarantined" or "flickering")
3. Release happens on Monday regardless of the state of the tests.
-1. For any failing test we must verify if the problem is a test issue or a real bug. If it's a real bug we need to analyze the criticity. If it's critical we shouldn't release without fixing it. If it's not critical then we can release but we'll need to add this information in the Release notes if it's a regression.
I am happy to hold the release until you give the okay. I volunteer to get the storage tests running.
Caleb
Since the release date is upon us, I need a quick response on this.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On May 30, 2011, at 9:14 AM, Denis Gervalle wrote:
I follow Thomas and Vincent on this. We should not hustled the release just to be on schedule.
I didn't say this ;) We need to be on schedule and do time boxing. Same as Thomas, I agree about rollbacking stuff that break tests. Committers should never break tests or if they do they need to fix that immediately and not wait several days. Since we know we have some stabilization issues it's also good to do what Caleb has started, ie start the stabilization a few days before the release and monitor commits and roll them back if they break anything, possibly even branch at that time to isolate the release to come. Thanks -Vincent
Denis
On Thu, May 26, 2011 at 14:44, Caleb James DeLisle <[email protected]
wrote:
On 05/26/2011 06:06 AM, Vincent Massol wrote:
Hi Caleb,
On May 26, 2011, at 5:03 AM, Caleb James DeLisle wrote:
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with the milestone release dates but now is the time to get this in order. I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability.
+1
2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
+1, we should also add a keyword so that we can easily filter them out (I propose "quarantined" or "flickering")
3. Release happens on Monday regardless of the state of the tests.
-1. For any failing test we must verify if the problem is a test issue or a real bug. If it's a real bug we need to analyze the criticity. If it's critical we shouldn't release without fixing it. If it's not critical then we can release but we'll need to add this information in the Release notes if it's a regression.
I am happy to hold the release until you give the okay. I volunteer to get the storage tests running.
Caleb
Since the release date is upon us, I need a quick response on this.
Thanks -Vincent
participants (6)
-
Caleb James DeLisle -
Denis Gervalle -
Luca Anca -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol