Re: [Xen-devel] Upcoming RC0

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, May 3, 2013 at 4:38 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 03.05.13 at 16:21, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel