From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Xen 4.7 Development Update Date: Tue, 1 Dec 2015 12:35:02 +0000 Message-ID: <20151201123502.GR21588@citrix.com> References: <1448417874.4046.10.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a3k9E-0005pm-Ag for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 12:35:08 +0000 Content-Disposition: inline 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: Lars Kurth Cc: "xen-devel@lists.xenproject.org" , "wei.liu2@citrix.com" , "Han, Huaitong" List-Id: xen-devel@lists.xenproject.org On Tue, Dec 01, 2015 at 11:54:54AM +0000, Lars Kurth wrote: > Wei, and others. > > > On 25 Nov 2015, at 02:17, Han, Huaitong > > wrote: > >> > >> = Projects = > > > > == Hypervisor == === x86 === *Memory protection keys for user pages > > -Huaitong Han > > one thing I struggle with (and I am probably not the only one), is > that it is not always easy do find out what a specific patch does in > the Development Update mails. Obviously this is not an issue at the > beginning of the cycle, but it can become one when we start to put the > release notes and PR together. In this particular case, the use-case > for the feature was described as a one-liner else-where and I am > wondering, whether we should allow tracking the use/use-case/... in > these mails. > > Aka, in this case, using the information from the thread where the > use-case was discussed, will give us something like ... > > == Hypervisor == === x86 === * Memory protection keys for user pages > (allows threads to cooperatively prevent themselves from "trampling" > on each other, which increases robustness and is useful for debugging) > - Huaitong Han > > Part of the reason, why I am also looking at this, is because of the > Feature Lifecycle Management (see > http://xen.markmail.org/message/uu3vifjmv2qylds4), where we still have > outstanding issues on documenting completed features. It seems to me > that there is an overlap between the Development Update mails, and > recording the state of an added feature in a central file. Obviously, > if a new feature was committed to xen.git, we would then need to add > an entry to the still to be defined central file describing it. And it > would probably make sense to keep the info in Development Update mails > as close as possible to what is in the still to be defined file. > I can't think of how you would merge such document and this email as a whole. Most things in this mail are unfinished so they haven't entered FML. If there is ever overlapped, that is the "completed" section of this mail -- it makes sense to keep that section close to the in-tree document. But on the flip side we don't need two places for the same thing so I would just remove the completed section all together and refer to the in-tree document. As for PR purpose it would be easy during freeze to send out emails to people to have them write a small paragraph. They are also welcome to provide such information to this email -- I shall say that in preamble. Wei. > Any thoughts? > > Cheers Lars > >