Xen project Mailing List

Hi all,

I have been travelling on Friday and wanted to appeal for calm on this particular issue. Let's try and focus on making as much progress as we can on the patch series which have freeze exceptions (or partial freeze exception) this week. Continuing a debate on what may have gone wrong with Remus/COLO or other series at this stage is going to be distracting and will affect everyones chances to get the remaining code with freeze exceptions into Xen 4.6. So please, let's focus on making as much progress as we can this week. Having said that, it is absolutely true that the first Remus/COLO and COLO RFC patches have received very little or no review time when they were posted first by Wen Congyang in April 2013. And that situation had not changed until a year later, when the issue was first raised with me (if I recall correctly).

I do sincerely apologise for this. Personally I would like to see COLO in Xen 4.6, but this is not my decision.

I do also believe that there has been tremendous progress on Remus and COLO in the last 12 months. There has also been great collaboration between maintainers and contributors in the last 12 months, in particular around Remus and COLOPre. Let's build on this and move forward.

= After July 24th =

We should have a discussion *after* July 24th, to see what is going wrong and what we can improve as a community. We can also cover some of the accusations that were made then. It is clear that as a community we do have some issues and challenges that we have to address. I have to personally take responsibility for underestimating some of the issues we face: until about 4 weeks ago, it looked as if many of the issues that I knew of are well on the way of being resolved. I honestly believe that many of the changes we made recently, such as focus on designs, had a very positive effect. I do not believe, that what we are seeing is a sign of a dying community. There were also some specific issues related to Remus/COLO: some have been addressed; others have not yet been addressed.

However, it is not clear yet from the data that I can mine, exactly what is going on in the general case. We have good data mining capability when it comes to git, but *no* data mining capability when it comes to the review process. I am meeting Bitergia tomorrow to see whether they (or I) can implement some functionality that allows us to get metrics related to the review process.

= Data we have =

What is interesting is that since 2012, we have seen an average annual increase of 9% of patches that made it into the Xen Hypervisor. We also have seen a slightly higher increase of Reviewed-by and ACKED-by tags during the same time period (around 10% a year). However, this does not tell us much, as the review period leading up to commits is not covered by git data.

The following graph shows the number of e-mails related to patches on xen-devel@ - both patches, comments on patches, submissions of new versions of patches, etc.

What is striking is that the ratio of discussions related to patches (including posted patches) on xen-devel divided by the patches that made it into Xen has increased almost grown exponentially recently: 5.85 (2012), 7.89 (2013), 8.63 (2014) to 11.65 (2015). This clearly shows that we have some issues with code reviews that are getting worse and that there is an underlying issue which we have to address: there are a number of possible reasons. But let's not speculate now.

Best Regards

Lars

On 17 Jul 2015, at 09:04, Eddie Dong <13341687268@xxxxxxx> wrote:

> If I can take one example, 11/25 "tools/libxc: support to resume uncooperative
> HVM guests". Based on my current understanding this is even a bugfix. Sadly it
> is not quite ready (or at least, wasn't last night). But with a few more days we
> can probably get much of this cleanup and preparatory work in.

I solicited Wei to give an 2-3 weeks exception time for the patch to be in much better shape, however, people simply ignore request not from Citrix without any retrospection to see where is the problem. I already heard many "believes" and "commitments" from people with the hat of maintainers and managers, saying that he/she should be able to complete the dependency patch couple weeks before the deadline during Xen Hackathon, and agreed to raise the priority to review the patches. But was any of those commitment really made?

Be aware this pushing effort has been lasting for 2 years already, it is not this week, this month, this quarter, even not only this year.

Resorting this to one or two technical issue simply doesn't work. People with the maintainer's hat on can arbitrary re-version the existing APIs for their hobby, to block all the follow-up patches for entire release cycles, which is one entire year. In the XEN/COLO case, it is 2 years for similar reasons.

>
> Assuming nothing goes horribly wrong, I am very optimistic about COLO making
> it upstream soon, just not in 4.6.
>

I heard similar word one year ago too, eveything is repeating without any retrospection: everything Citrix likes, they can happen at any time anywhere ... Everything else, have to resort to the Citrix maintainers to has redundant bandwidth.

Any developers from PRC, it is time for you guys to move to other hypervisors. Xen is a Citrix's hobby only, and no longer an active community project. If you couldn't prepare for at least 2 years efforts to push a patch series, Eddie personally would like to suggest you to move to other hypervisors.

From a former 11+ years experience Xen community developer, Xen spot light, and Xen active participant.
Eddie Dong

æè çæææåçéç -- æææåæçæææåçéçïäèèæ>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

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