From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Request a freeze exception for COLO in v4.6 Date: Mon, 20 Jul 2015 07:02:06 -0700 Message-ID: <582B7F84-1E25-44F2-B711-D49C6E86F8A6@gmail.com> References: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/mixed; boundary="===============8735419515119871069==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Xen Devel List-Id: xen-devel@lists.xenproject.org --===============8735419515119871069== Content-Type: multipart/alternative; boundary="Apple-Mail=_91CA5807-87DC-4700-91DB-8D28B9A648D5" --Apple-Mail=_91CA5807-87DC-4700-91DB-8D28B9A648D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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).=20 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. =3D After July 24th =3D 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. =3D Data we have =3D 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@163.com> wrote: >=20 > > 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 >=20 > > is not quite ready (or at least, wasn't last night). But with a few = more days we >=20 > > can probably get much of this cleanup and preparatory work in. >=20 > =20 >=20 > 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? >=20 > =20 >=20 > 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. >=20 > =20 >=20 > 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. >=20 > =20 >=20 > > >=20 > > Assuming nothing goes horribly wrong, I am very optimistic about = COLO making >=20 > > it upstream soon, just not in 4.6. >=20 > > >=20 > =20 >=20 > 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. >=20 > 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. >=20 > =46rom a former 11+ years experience Xen community developer, Xen spot = light, and Xen active participant. > Eddie Dong >=20 >=20 > =E6=9D=A5=E8=87=AA =E7=BD=91=E6=98=93=E6=89=8B=E6=9C=BA=E5=8F=B7=E7=A0=81= =E9=82=AE=E7=AE=B1 -- = =E6=9C=89=E6=89=8B=E6=9C=BA=E5=B0=B1=E6=9C=89=E7=BD=91=E6=98=93=E6=89=8B=E6= =9C=BA=E5=8F=B7=E7=A0=81=E9=82=AE=E7=AE=B1=EF=BC=8C=E4=BA=86=E8=A7=A3=E8=AF= =A6=E6=83=85> = _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --Apple-Mail=_91CA5807-87DC-4700-91DB-8D28B9A648D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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.

=3D After July 24th = =3D

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.

=3D = Data we have =3D

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@163.com>= 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.

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


=E6=9D=A5=E8= =87=AA =E7=BD=91=E6=98=93=E6=89=8B=E6=9C=BA=E5=8F=B7=E7=A0=81=E9= =82=AE=E7=AE=B1 -- =E6=9C=89=E6=89=8B=E6=9C=BA=E5=B0=B1=E6=9C=89=E7=BD= =91=E6=98=93=E6=89=8B=E6=9C=BA=E5=8F=B7=E7=A0=81=E9=82=AE=E7=AE=B1=EF=BC=8C= =E4=BA=86=E8=A7=A3=E8=AF=A6=E6=83=85>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

= --Apple-Mail=_91CA5807-87DC-4700-91DB-8D28B9A648D5-- --===============8735419515119871069== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8735419515119871069==--