[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.7 Development Update
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 <huaitong.han@xxxxxxxxx> > > 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 > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |