Re: [Xen-devel] Xen 4.3 development update

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Sep 20, 2012 at 8:03 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>> * Feature Freeze: 1 March, 2013
>> * First RC: 15 April 2013
>> * Release: 1 June 2013
>
> While it's only slightly over two weeks - didn't we agree to count
> from the release date (rather than the intended one)?

So we did.  And if we actually do 6 weeks for each milestone, that gives us:

* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

Sound reasonable?

>> * Persistent grants
>>   owner: @citrix
>>   status: ?
>
> Isn't that a guest side only thing (i.e. not really to be tracked
> here)? Or does that mean migrating active grants?

It is a bit funny to have Linux-side stuff tracked here, since it has
its own release schedule; but there's not really a better place to
track it.  For both a "look at the great stuff happening" aspect, and
a "what needs to be done and who is going to do it when" aspect,
having all of the various development activities in one place is an
advantage.

>> * Scalability: 16TiB of RAM
>>   owner: jan@suse
>>   status: ?
>
> Not started.
>
>> * Linux console improvements
>>   owner: jan@suse
>>   -EHCI debug port (done, to be submitted)
>
> Committed.

Excellent; first to go under the (newly-created) "completed" category.

>>   -xHCI debug port
>
> This one needs an owner having access to suitable hardware _and_
> knowledge of the protocol since, other than for EHCI, there isn't
> even a reference implementation (e.g. in Linux) to clone from. I'd
> therefore rather consider this nice-to-have than a firm plan to have
> such functionality.
>
>>   -Firewire
>
> Largely same here - while I'm not suffering from lack of hardware
> (apart from - afaict - cables), I've never done anything with
> Firewire, and hence would consider this one as well nice-to-have
> only.

"Nice-to-have" vs "blocker" is more something that will need to be
considered near the feature freeze.  There are a handful of things
that the Citrix team, internally, have deemed "critical" -- that is,
if they seem to be in danger of missing, we will divert resources in
order to help them make 4.3; but other than those, I think basically
all the features in this list would be "nice-to-have".

Perhaps what we really need is a way to track the probability of
success, so that those who want a particular feature to make it in can
take action if they need to; for example:
* Green: Owned, and no reason to think it won't make it in
* Yellow: At-risk; may need intervention to make it in
* Red: High probability of failure; possibly avert-able by immediate action
* Grey: Not owned, or something blocking; but no reason it couldn't
make it in if someone picks it up
* Black: Very unlikely to make it in; expected to be held off until
next release.

So in this scheme, the xHCI and Firewire would be "grey" -- no reason
to think they couldn't make it by the deadline, but it's blocked on
something.

Or, maybe that's more than we need at the moment. :-)  Thoughts?

 -George

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