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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> * 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.

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.

Jan


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