diff mbox

[Xen-devel] Use non-debug build for Xen 4.9

Message ID 20170518153829.10200-1-julien.grall@arm.com
State Accepted
Commit 229ff3125b3d43c3fdc87c12c0047894395b5d32
Headers show

Commit Message

Julien Grall May 18, 2017, 3:38 p.m. UTC
Modify Config.mk and Kconfig.debug to disable debug by default in
preparation for late RCs and eventual release.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 tools/Rules.mk    | 2 +-
 xen/Kconfig.debug | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Wei Liu May 18, 2017, 3:42 p.m. UTC | #1
On Thu, May 18, 2017 at 04:38:29PM +0100, Julien Grall wrote:
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson May 18, 2017, 5:40 p.m. UTC | #2
Julien Grall writes ("[PATCH] Use non-debug build for Xen 4.9"):
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich May 19, 2017, 6:47 a.m. UTC | #3
>>> On 18.05.17 at 17:38, <julien.grall@arm.com> wrote:
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

To avoid pointless code churn on the master branch, shouldn't this
be done only after (or even while) branching?

Jan
Julien Grall May 19, 2017, 7:32 a.m. UTC | #4
Hi Jan,

On 19/05/2017 07:47, Jan Beulich wrote:
>>>> On 18.05.17 at 17:38, <julien.grall@arm.com> wrote:
>> Modify Config.mk and Kconfig.debug to disable debug by default in
>> preparation for late RCs and eventual release.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> To avoid pointless code churn on the master branch, shouldn't this
> be done only after (or even while) branching?

I don't think we are in state to branch right now (we still haven't had 
a push in master after the last force push...) and I would like to have 
the debug disable as soon as possible to get more testing.

Cheers,
Ian Jackson May 19, 2017, 10:27 a.m. UTC | #5
Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> On 18.05.17 at 17:38, <julien.grall@arm.com> wrote:
> > Modify Config.mk and Kconfig.debug to disable debug by default in
> > preparation for late RCs and eventual release.
> > 
> > Signed-off-by: Julien Grall <julien.grall@arm.com>
> 
> To avoid pointless code churn on the master branch, shouldn't this
> be done only after (or even while) branching?

I think it's fine either way.

(And yes, apropos of Julien's other message, we should branch with
staging==master.)

Ian.
Julien Grall May 19, 2017, 1:23 p.m. UTC | #6
Hi,

On 19/05/17 11:27, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
>> On 18.05.17 at 17:38, <julien.grall@arm.com> wrote:
>>> Modify Config.mk and Kconfig.debug to disable debug by default in
>>> preparation for late RCs and eventual release.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>
>> To avoid pointless code churn on the master branch, shouldn't this
>> be done only after (or even while) branching?
>
> I think it's fine either way.
>
> (And yes, apropos of Julien's other message, we should branch with
> staging==master.)

Could someone push this patch to staging, I'd like to include that in 
the next RC.

Regarding the branching, I was thinking to branch right after the next 
RC. Any opinions on this?

Cheers,
Wei Liu May 19, 2017, 1:39 p.m. UTC | #7
On Fri, May 19, 2017 at 02:23:42PM +0100, Julien Grall wrote:
> Hi,
> 
> On 19/05/17 11:27, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> > > On 18.05.17 at 17:38, <julien.grall@arm.com> wrote:
> > > > Modify Config.mk and Kconfig.debug to disable debug by default in
> > > > preparation for late RCs and eventual release.
> > > > 
> > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > 
> > > To avoid pointless code churn on the master branch, shouldn't this
> > > be done only after (or even while) branching?
> > 
> > I think it's fine either way.
> > 
> > (And yes, apropos of Julien's other message, we should branch with
> > staging==master.)
> 
> Could someone push this patch to staging, I'd like to include that in the
> next RC.

Done. Along with some other patches.

> 
> Regarding the branching, I was thinking to branch right after the next RC.
> Any opinions on this?
> 

+1

> Cheers,
> 
> -- 
> Julien Grall
Ian Jackson May 19, 2017, 1:58 p.m. UTC | #8
Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> Regarding the branching, I was thinking to branch right after the next 
> RC. Any opinions on this?

That would be fine by me.  We would want staging==master at the time
we branch, so we should have a commit moratorium too.

Ian.
Julien Grall May 19, 2017, 1:59 p.m. UTC | #9
On 19/05/17 14:58, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
>> Regarding the branching, I was thinking to branch right after the next
>> RC. Any opinions on this?
>
> That would be fine by me.  We would want staging==master at the time
> we branch, so we should have a commit moratorium too.

Good point. I will send an e-mail for that.

Cheers,
diff mbox

Patch

diff --git a/tools/Rules.mk b/tools/Rules.mk
index f55fb669b8..c3fdbc4d4f 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -30,7 +30,7 @@  CFLAGS_xeninclude = -I$(XEN_INCLUDE)
 XENSTORE_XENSTORED ?= y
 
 # A debug build of tools?
-debug ?= y
+debug ?= n
 debug_symbols ?= $(debug)
 
 # Set CONFIG_GOLANG=y in .config (or in make) to build golang
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 689f2974c0..e01a194091 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -3,7 +3,7 @@  menu "Debugging Options"
 
 config DEBUG
 	bool "Developer Checks"
-	default y
+	default n
 	---help---
 	  If you say Y here this will enable developer checks such as asserts
 	  and extra printks. This option is intended for development purposes