Re: [Xen-devel] Request a freeze exception for COLO in v4.6

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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

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