Re: [Xen-devel] Xen 4.3 release planning proposal

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Aug 21, 2012 at 3:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 20.08.12 at 18:46, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> So I propose that we move to a time-based release schedule.  Rather
>> than aiming for a release date, I propose that we aim to do a "feature
>> freeze" six months after the 4.2 release -- that would be around March
>> 1, 2013.  That way we'll probably end up releasing in 9 months' time,
>> around June 2013.  This is one of the things we can discuss at the Dev
>> Meeting before the Xen Summit next week.  If you have other opinions,
>> please let us know.
>
> That would make for a scheduled 3 month feature freeze. I don't
> recall for how long we've been in feature freeze for 4.2 now, but
> from my perspective this is already definitely too long. Over that
> time I accumulated around 50 patches (not counting the bug fixes
> that I keep posting), and I'm sure it was never that bad during
> earlier feature freeze periods.

I think it's been nearly 5 months.  The main reason for the long
feature freeze, as far as I can tell, is that we did the freeze too
early; there were several major components (namely a stable libxl api)
that were nowhere near ready.  I'm hoping to avoid that this time by
having a clearer idea what we want from the release; features that
will be blockers must be in a reasonable state before we freeze.

A 3-month freeze is basically 6 weeks of clean-up and bug-fixing, and
6 weeks of RCs, which seems pretty realistic to me.  Feel free to
suggest another break-down if you want. :-)

>> * Event channel scalability
>>   owner: attilio@citrix
>>   Increase limit on event channels (currently 1024 for 32-bit guests,
>>   4096 for 64-bit guests)
>
> This one I have on my todo list as well.

I would say, "You should coordinate with Attilio", but I see Attilio
has already responded. :-)

>
> Bigger things that I have ready to be submitted (and that aren't
> cleanup in a more or less strong sense) are an EHCI debug port
> driver for the console and a port of the CPUID based (i.e. not
> requiring ACPI data to be passed from Dom0) idle driver from
> Linux.
>
> Larger things I have on my todo list and didn't see in yours are
> - breaking the 5Tb memory barrier (for the moment aiming at
>   16Tb due to certain implementation details)
> - an xHCI debug port driver for the console (no Linux driver to
>   clone from so far, so needs someone with good knowledge of
>   the device and access to hardware, neither of which is the
>   case for me, or finding out whether this is already in the works
>   on the Linux side)
> - if possible, a FireWire based console driver (but I've never done
>   anything with FireWire, so it would depend on me finding ample
>   time to first play with and then work on this)
> - getting the public headers x32-clean
>
> Plus there's one tools side item that I was asked to raise in the
> course of 4.3 planning/development, but which I'm unlikely to
> work on myself - removal of the hard code modprobe-s from
> xencommons, properly loading the needed modules on demand
> from the tool stack.

Great, thanks Jan -- I've put all of these on my list.

 -Geoge

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