From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dong, Eddie" Subject: Re: Request a freeze exception for COLO in v4.6 Date: Fri, 17 Jul 2015 00:15:50 +0000 Message-ID: References: <55A6332D.7070000@cn.fujitsu.com> <20150716150058.GT12455@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150716150058.GT12455@zion.uk.xensource.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Yang Hongyang Cc: Ian Campbell , Wen Congyang , Andrew Cooper , "Jiang, Yunhong" , Ian Jackson , "xen-devel@lists.xen.org" , "Dong, Eddie" , Gui Jianfeng List-Id: xen-devel@lists.xenproject.org > > There are currently 50 patches related to COLO pending reviews and acks > (25 pre + 25 COLO itself). Some pre patches are acked but there are still some > comments regarding implementation details in the pre patches and COLO itself is > still lacking review. Further more, migration v2 is having some issues and has > not passed the push gate (this is not really your fault). > > Given the above situation it's hard for me to justify granting a freeze exception > to these 50 patches. However I do understand it is painful for you to carry so > many patches and the burden of constantly rebasing so I'm thinking about > granting freeze exception to those patches that are pure code motion / low risk > refactoring in the pre series, to reduce your load of work. > > As for the rest patches (rest in pre and COLO itself), I talked to Ian Jackson about > this and he's quite optimistic about getting COLO in for 4.7. > > Ian and Ian, anything to add? What are your opinions? > I have been working in Xen for 11 years, witness the entire progress Xen made in the past, from incubation to mature and now. I never spoke for myself. Now I want speak for myself, not for Intel. A feature like COLO has been pushing for ~2 years with professional effort from developers, but it was still gated. I didn't see any introspection from the community, while I was kept telling Xen needs COLO, from the time when Lars visit Shanghai 2 years ago. Yes, it does have 25 pre patches and 25 function patches, but they are not new, they are posted in the mailinglist for months already, and have been waiting for reviews all the time. Why we couldn't do it before? Why it becomes the reason to block it? Is the community revising himself? Why we couldn't be frank here? Like Linus does to many features he dislike, simply say Xen doesn't need COLO, that is fine. However I felt I was kept telling that COLO is important to Xen, while maintainers doesn't have bandwidth to review, from the time a few months before Xen 4.5. Things didn't change in Xen 4.6, people kept changing the code base that COLO are depending, and again block COLO. Lars and Wei and all the maintainers: Life can be much easier if we are all frank! You save effort and we save effort, and everybody are happy then: We do have plenty of new features to do, why we stick with Xen/COLO? I still remembered when I firstly presented COLO in Xen Summit'2011 in San Diego, when Keir and Ian were still in chairing. At that time, Xen are still leading no matter in new feature and/or adoption... How fast the world changes and how fast the community changes after 4 years. For people who participating in Xen/COLO effort: if you join the effort because of Eddie, please take a rest and try to do something more interesting, you have done very well in the past, and it was time to call it a stage. OSVs who want Xen/COLO, they can pull the patch series themselves, and if they don't need, they don't need even if you pushed it into upstream. I ever championed the effort to support Xen for COLO, but that is as of today only. I saw Xen was sinking for a while and now I felt it was dying quickly ... God Bless Xen!! From today, after serving in the community for 11 and a half years, I was no longer a Xen community member and I will appeal people to leave Xen too ... Intel colleagues: Please remove my name from VMX subsystem as a sub-maintainer. Thx Eddie