From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yong Wang Subject: Re: Xen 4.7 Development Update Date: Tue, 1 Dec 2015 21:32:55 +0800 Message-ID: <20151201133255.GA7868@ywang-linux> 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 1a3l4x-0002y1-RQ for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 13:34:47 +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. > > Any thoughts? > Isn't such information typically available in patch header (or patch 0 whatever you call it)? As developers start posting patches of the particular feature, can release manager add such info to the development update email if this can make Lars' life easier when he needs to compile such info for PR;-) Thanks -Yong