qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] release retrospective, next release timing, numbering


From: Cornelia Huck
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Mon, 30 Apr 2018 11:29:06 +0200

On Fri, 27 Apr 2018 16:51:03 +0100
Peter Maydell <address@hidden> wrote:

> Hi; I usually let people forget about releases for a month or
> so before bringing this topic up, but:
> 
> (1) do we want to call the next release 2.13, or something else?
> There's no particular reason to bump to 3.0 except some combination of
>  * if we keep going like this we'll get up to 2.42, which starts to
>    get silly
>  * Linus-style "avoid being too predictable"
>  * triskaidekaphobia

* avoiding that this discussion comes up every release :)

> but maybe we should anyway?

v3.0 sounds fine to me.

> 
> (2) release timing:
>  * usual schedule would give us a next release mid-to-late August
>  * unless I can persuade Stefan to do the release management this
>    cycle we might need to wind that in by a couple of weeks so
>    it's definitely done by the middle of August, to avoid a clash
>    with a personal commitment
>  * so probably hardfreeze 10th July, softfreeze 3rd July

August might be more of a vacation month than July, anyway? (Depending
on where you live, I guess.)

No objection from me.

> 
> (3) retrospective, lessons learned &c
>  * please remember that if every single submaintainer submits
>    a pull request on the morning of an RC, it is physically
>    not possible for me to process all those pulls in time to
>    tag the RC that day. We had several RCs which got delayed
>    by a day because of this; please try to submit earlier
>    rather than later...

There seemed to have been several 'oh crap' issues that people wanted
to get in asap, so that might account for it.

On a related note: During the development phase, does it make more
sense to collect stuff until you have a big pile of patches, or is it
better (from an integration perspective) to do more frequent, smaller
pull requests?

>  * provide your opinions here ?
> 
> thanks
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]