We''re scheduled to do an RC next week; originally it was Monday, but that''s a bank holiday here in the UK, so many of us will be off work; so I propose doing one on Tuesday. IanC suggested that we should have a short code-freeze window before each RC to make sure that nothing is introduced that will cause test failures. So I''m asking committers to hold off on committing anything that is not directly related to making the tests pass, or to fixing specific issues that need to be fixed before RC0. The one major bug we have outstanding is the RTC one -- as that basically prevents w2k3 from working at all, it would be good to have that one fixed if possible by the test day on Wednesday. Keir, IanC, IanJ, do you guys have any opinions on this one? Jan thinks that since we have an understanding of what the issue is, and a patch series that fixes the problem (as far as we can tell) for w2k3. Tim things we just don''t have enough time to be sure we can catch all the bugs, so we should revert all the RTC made in the last few months. I can see the point of both sides; however, Tim found some issues even in the patch series that Jan posted recently, which (sorry to be frank, Jan) doesn''t give me confidence that we won''t have random bugs that we end up tripping over after the release. Overall I''d rather defer to Tim, Jan, and Keir; but if I were asked to make a recommendation, I would go with Tim''s. As long, that is, as we are confident that we can back the changes out easily. If reverting the changes is a complicated business, we risk bugs either way; in which case we might as well move forward. -George
At 15:21 +0100 on 03 May (1367594473), George Dunlap wrote:> IanC suggested that we should have a short code-freeze window before > each RC to make sure that nothing is introduced that will cause test > failures. So I''m asking committers to hold off on committing anything > that is not directly related to making the tests pass, or to fixing > specific issues that need to be fixed before RC0.Ack.> The one major bug we have outstanding is the RTC one -- as that > basically prevents w2k3 from working at all, it would be good to have > that one fixed if possible by the test day on Wednesday. > > Keir, IanC, IanJ, do you guys have any opinions on this one? > > Jan thinks that since we have an understanding of what the issue is, > and a patch series that fixes the problem (as far as we can tell) for > w2k3. > > Tim things we just don''t have enough time to be sure we can catch all > the bugs, so we should revert all the RTC made in the last few months.Well, mainly the one change that scares me is the switch from having vpt inject the interrupts to having RTC code (conditionally) inject them. Unfortunately, given the amount of fixes that have followed that code, it''s not as simple as a plain revert of a single patch. And I have _no_ time between now and Tuesday to disentangle that one change with any confidence of doing it right. So with the release so close, I think it might be as well to revert all the RTC changes since 4.2. That includes reverting a few genuine fixes (but AIUI nothing that''s been seen in the field) to get to a known good state. Then we apply ''em all again as soon as we branch[1]. The other option is to take the rest of Jan''s current series, which keeps all the code changes but disables the end result. IMHO, this needs someone to commit to serious testing, esp. of all the old crusty OSes that are likely to rely on the RTC''s behaviour. And at the end we don''t get the main benefit (avoiding pointless timer interrupts) either way. Tim. [1] When are we branching, btw? At rc0 or later?> I can see the point of both sides; however, Tim found some issues even > in the patch series that Jan posted recently, which (sorry to be > frank, Jan) doesn''t give me confidence that we won''t have random bugs > that we end up tripping over after the release. > > Overall I''d rather defer to Tim, Jan, and Keir; but if I were asked to > make a recommendation, I would go with Tim''s. > > As long, that is, as we are confident that we can back the changes out > easily. If reverting the changes is a complicated business, we risk > bugs either way; in which case we might as well move forward. > > -George
>>> On 03.05.13 at 16:21, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > IanC suggested that we should have a short code-freeze window before > each RC to make sure that nothing is introduced that will cause test > failures. So I''m asking committers to hold off on committing anything > that is not directly related to making the tests pass, or to fixing > specific issues that need to be fixed before RC0.While I''m not opposed to this, "short" certainly deserves some sort of definition. Also, traditionally we never did RC0s, we always started with RC1 - any reason for this change? Further, as to branching (which Tim also asked about) - traditionally we branched at a late RC, and only then re-opened the tree for new development. Is that going to change this time? I can see both pros and cons to either approach...> I can see the point of both sides; however, Tim found some issues even > in the patch series that Jan posted recently, which (sorry to be > frank, Jan) doesn''t give me confidence that we won''t have random bugs > that we end up tripping over after the release.I thought you would say that (and I understand your reservations). Nevertheless, the problematic patch was withdrawn after Tim''s review, so this shouldn''t stand in the way. And no, I can''t give 100% guarantees that the rest is entirely bug free. Jan
On Fri, May 3, 2013 at 4:38 PM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 03.05.13 at 16:21, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> IanC suggested that we should have a short code-freeze window before >> each RC to make sure that nothing is introduced that will cause test >> failures. So I''m asking committers to hold off on committing anything >> that is not directly related to making the tests pass, or to fixing >> specific issues that need to be fixed before RC0. > > While I''m not opposed to this, "short" certainly deserves some > sort of definition.I suppose in practice it doens''t actually matter that much; it matters more this time because of the test day on Wednesday. If we close off commits today near the end of business day, then we''ll have the weekend for the regression testing. If it passes, we can cut an RC on Tuesday morning; if not, we have Tuesday to fix it, which would be tight.> Also, traditionally we never did RC0s, we always started with RC1 > - any reason for this change?No reason -- we can go back to tradition if we want. It just seems more fitting as computer programmers to start from 0. :-)> Further, as to branching (which Tim also asked about) - traditionally > we branched at a late RC, and only then re-opened the tree for > new development. Is that going to change this time? I can see both > pros and cons to either approach...I don''t have a strong opinion yet. A couple of factors: * I think having the tree closed helps people to focus more on testing and bug-fixing. * Branching means bug fixes need to be ported and applied two places So overall I think I would hold off branching until we think trunk is sufficiently well tested that it might be release-able, except that it has a few well-known bugs that will take some time to complete. But like I said, that''s just an early inclination. I think I''ll probably bring this up the next time I send out a 4.3 update e-mail, so it has more chance of garning people''s attention.>> I can see the point of both sides; however, Tim found some issues even >> in the patch series that Jan posted recently, which (sorry to be >> frank, Jan) doesn''t give me confidence that we won''t have random bugs >> that we end up tripping over after the release. > > I thought you would say that (and I understand your reservations). > Nevertheless, the problematic patch was withdrawn after Tim''s > review, so this shouldn''t stand in the way. And no, I can''t give 100% > guarantees that the rest is entirely bug free.100% guarantees are for the most part not available in this world. :-) Neither can Tim guarantee that some other bit of the code hasn''t been changed to rely on the behavior he suggests reverting. But we can try to estimate the probabilities and try to choose the course most likely to help us reach our goals. And at the moment, Tim''s suggestion seems (to me) to be lower risk. If you have any arguments to strengthen my confidence in your patch series, or undermine my confidence in Tim''s suggestion, feel free to share them. :-) -George