Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 26/01/17 17:06, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 12:27:15PM +0000, Julien Grall wrote:
> > Hi,
> >
> > On 09/12/2016 19:09, Andrew Cooper wrote:
> > > On 09/12/16 19:01, Stefano Stabellini wrote:
> > > > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> > > > > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > > > > > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> > > > > > > > > Should we have a section on new PV drivers? If so, I suggest to add:
> > > > > > > > > - Xen transport for 9pfs
> > > > > > > > > - PV Calls
> > > > > > > > Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> > > > > > > This is a great idea. Let me explain what we have and what the direction
> > > > > > > is:
> > > > > > > 1. Frontends which we already have, working, but need to refactor/cleanup:
> > > > > > > 1.1. PV sound
> > > > > > > 1.2. PV DRM
> > > > > > > 1.3. DISPL protocol, I will push v1 for review right after sndif done
> > > > > > > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
> > > > > > > via DRM Prime buffer sharing)
> > > > > > > 1.4. PV events not done, but we are considering [1]. If it fits and
> > > > > > > is maintained,
> > > > > > > then we'll probably stick to it, otherwise new PV will be created
> > > > > > >
> > > > > > > 2. Backends, for the above frontends already implemented:
> > > > > > > 2.1. A unified library for Xen backends (libxenbe)
> > > > > > > 2.2. DRM + Wayland
> > > > > > > 2.3. ALSA
> > > > > > > 2.4. Events not implemented yet
> > > > > > >
> > > > > > > All the above sources are available on *public* Github repos
> > > > > > > (I can provide links on request) and the intention is to
> > > > > > > upstream.
> > > > > > Please do post the links..
> > > > > Please note these are all WIP:
> > > > > 1. Frontends
> > > > > https://github.com/andr2000?tab=repositories
> > > > > 2. Backends
> > > > > https://github.com/al1img?tab=repositories
> > > > Now, I don't want to sound pessimistic, but I thought I was being
> > > > audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> > > > think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> > > > PV DRM frontends and backends, all by April? I would probably reduce the
> > > > list a bit.
> > > I think it would be good to main two lists.  One of "the stuff people
> > > are working on overall", and "the subset of it intended/expected for the
> > > forthcoming release".
> > >
> > > Stuff will invariably slip, but even if the work isn't intended for the
> > > forthcoming release, it it still useful to see if anyone in the
> > > community is working on a related topic.
> > I am thinking to re-introduce the state of a series (none, fair, ok, good,
> > done) as it was done in the past [1].
> >
> > "The states are: none -> fair -> ok -> good -> done
> >
> > none - nothing yet
> > fair - still working on it, patches are prototypes or RFC
> > ok   - patches posted, acting on review
> > good - some last minute pieces
> > done - all done, might have bugs"
> We (I?) ditched them because they weren't that useful.  "None" is just
> signalling of intent, which doesn't carry enough of meaningful
> information.  "Fair", "ok" and "good" are all subjective -- we've seen
> "good" series slipped due to last minute issues.
>
> If we really want status, I would suggest more concrete status:
>
>   design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
>
> These are more tangible and objective.
I agree this is more objective but we loose the time estimation. The 
number of revisions sent depends a lot on the contributor, complexity of 
the series... So a series tagged wip.v5 might be in better shape of one 
tagged wip.v10.
Although, I don't have better idea so far.

Cheers,

--
Julien Grall

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