From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Xen 4.7 Development Update Date: Tue, 1 Dec 2015 11:54:54 +0000 Message-ID: References: <1448417874.4046.10.camel@intel.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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 1a3jWN-0002Ct-6W for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 11:54:59 +0000 Received: by wmuu63 with SMTP id u63so169446651wmu.0 for ; Tue, 01 Dec 2015 03:54:57 -0800 (PST) In-Reply-To: <1448417874.4046.10.camel@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "wei.liu2@citrix.com" Cc: "xen-devel@lists.xenproject.org" , "Han, Huaitong" List-Id: xen-devel@lists.xenproject.org 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? Cheers Lars