[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
- To: Wei Liu <wei.liu2@xxxxxxxxxx>, Lars Kurth <lars.kurth.xen@xxxxxxxxx>
- From: Lars Kurth <lars.kurth@xxxxxxxxxx>
- Date: Tue, 10 Feb 2015 19:29:30 +0000
- Accept-language: en-GB, en-US
- Cc: artem Mygaiev <artem.mygaiev@xxxxxxxxxxxxxxx>, "oleksandr.dmytryshyn@xxxxxxxxxxxxxxx" <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>, "cyliu@xxxxxxxx" <cyliu@xxxxxxxx>, Kelly Zytaruk <Kelly.Zytaruk@xxxxxxx>, "dongxiao.xu@xxxxxxxxx" <dongxiao.xu@xxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxx>, "JBeulich@xxxxxxxx" <JBeulich@xxxxxxxx>, "feng.wu@xxxxxxxxx" <feng.wu@xxxxxxxxx>, "zhigang.x.wang@xxxxxxxxxx" <zhigang.x.wang@xxxxxxxxxx>, Parth Dixit <parth.dixit@xxxxxxxxxx>, "dkiper@xxxxxxxxxxxx" <dkiper@xxxxxxxxxxxx>, "w1.huang@xxxxxxxxxxx" <w1.huang@xxxxxxxxxxx>, Vijay Kilari <vijay.kilari@xxxxxxxxx>, Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>, "Vijaya.Kumar@xxxxxxxxxxxxxxxxxx" <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>, "Tim \(Xen.org\)" <tim@xxxxxxx>, "zoltan.kiss@xxxxxxxxxx" <zoltan.kiss@xxxxxxxxxx>, "yang.z.zhang@xxxxxxxxx" <yang.z.zhang@xxxxxxxxx>, Serge Broslavsky <serge.broslavsky@xxxxxxxxxx>, Olaf Hering <olaf@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, "wency@xxxxxxxxxxxxxx" <wency@xxxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "shantong.kang@xxxxxxxxx" <shantong.kang@xxxxxxxxx>, Roy Franz <roy.franz@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Matt Wilson <msw@xxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, "dgdegra@xxxxxxxxxxxxx" <dgdegra@xxxxxxxxxxxxx>, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>, "aravindp@xxxxxxxxx" <aravindp@xxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Dario Faggioli <dario.faggioli@xxxxxxxxxx>, Eddie Dong <eddie.dong@xxxxxxxxx>, "edmund.h.white@xxxxxxxxx" <edmund.h.white@xxxxxxxxx>, Don Slutz <dslutz@xxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>, "Aravind.Gopalakrishnan@xxxxxxx" <Aravind.Gopalakrishnan@xxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, "Suravee.Suthikulpanit@xxxxxxx" <Suravee.Suthikulpanit@xxxxxxx>, "guijianfeng@xxxxxxxxxxxxxx" <guijianfeng@xxxxxxxxxxxxxx>, "Chen, Tiejun" <tiejun.chen@xxxxxxxxx>, "vkuznets@xxxxxxxxxx" <vkuznets@xxxxxxxxxx>, Hongyang Yang <yanghy@xxxxxxxxxxxxxx>, Daniel Kiper <daniel.kiper@xxxxxxxxxx>, Christoffer Dall <christoffer.dall@xxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 10 Feb 2015 19:30:00 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
- Thread-index: AQHQRUMWFM8iYnybX0Ws6tDFcoYE/pzqHKYAgAAHGQCAABC9gA==
- Thread-topic: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
Wei,
thanks for clarifying. I don't think you answered all the practical
implications of your proposal though.
A) Do we start making RC's straight after the Feature Freeze?
B) Will there still be exceptions? I am assuming yes
C) Do you expect a gradual decrease of what bug fixes are allowed after
the Feature Freeze?
If the answer is yes to A), we would have more RC's and more test days.
That means slightly more overhead but also - if we get good community
engagement - better quality.
If the answer is yes to C), the Release Manager would in essence have more
flexibility, but also has to make more decisions. The same applies to B).
I am not convinced that the hard freeze really would go away. It would
merely not be as cleanly identifiable and we would gradually move from
soft to hard freeze.
If the answer was NO to any of the questions above, I think you would need
to elaborate what the alternatives are.
Cheers
Lars
On 10/02/2015 18:29, "Wei Liu" <wei.liu2@xxxxxxxxxx> wrote:
>On Tue, Feb 10, 2015 at 06:04:10PM +0000, Lars Kurth wrote:
>> Wei,
>> could you explain what you mean by soft freeze and hard freeze.
>> Regards
>
>They correspond to feature freeze and code freeze respectively.
>
>A bit more background information for developers that are new to the
>community. In 4.5 and 4.4 there were two freezes, one called feature
>freeze (soft freeze), the other called code freeze (hard freeze).
>
>In 4.4 and 4.5, feature posted before feature freeze but didn't get in
>before feature freeze still have a chance to get merged, provided that
>1) it's in good shape, 2) there is a strong argument that it should be
>merged. Code freeze is the strict freezing point, when no more new
>features can go in after that.
>
>That model has its pros and cons. I proposed in my previous email to
>just scrap the feature freeze and go with only code freeze, with the
>hope to create shorter release cycle and smoother workflow.
>
>Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
