On Wed, 2011-09-28 at 00:46 +0200, Michael Stahl wrote:
On 27.09.2011 10:33, Michael Meeks wrote:
Sure sure, so - I think Stephan has a point - that we ought to find
some way of enabling this for some set of people that can cope with it.
I suspect a good heuristic would be to have an
On 28.09.2011 10:42, Caolán McNamara wrote:
On Wed, 2011-09-28 at 00:46 +0200, Michael Stahl wrote:
On 27.09.2011 10:33, Michael Meeks wrote:
Sure sure, so - I think Stephan has a point - that we ought to find
some way of enabling this for some set of people that can cope with it.
I
Hi Marc,
On Tue, 2011-09-27 at 10:06 +0530, Marc-André Laverdière wrote:
That experience lead me to believe that the policy
should be make it easy for the n00b.
Quite; easy, and friendly too :-)
When I tried using this flag, I ended up not being able to _build_ at
all. And that
I actually like the auto-detect idea! As long as we still have an
option to turn it off in case it is misbehaving :)
Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India
On Tue 27 Sep 2011 02:03:59 PM IST, Michael Meeks wrote:
Hi Marc,
On 09/27/2011 10:33 AM, Michael Meeks wrote:
On Tue, 2011-09-27 at 10:06 +0530, Marc-André Laverdière wrote:
When I tried using this flag, I ended up not being able to _build_ at
all. And that wasn't even due to my own mistake, only some module I
know nothing at all is breaking the build.
Hi Bjoern,
On Mon, 2011-09-26 at 19:47 +0200, Bjoern Michaelsen wrote:
This seems to me to be a bit overzealous. Invoking the impression that
development on branches is oldschool and obsolete is just wrong --
There is no problem with working on branches, indeed - I'm actively
working
On Tue, 27 Sep 2011 10:24:12 +0100
Michael Meeks michael.me...@novell.com
wrote:
and it seems unclear what the benefit vs. the pain pwrt.
when re-synching (around deleting old remote branches etc.) would be.
Given enough eyeballs all bugs are shallow. Having commits visible
some time before
On 09/26/2011 08:41 AM, Stephan Bergmann wrote:
Just a friendly reminder that all developers should use --enable-werror
all the time.
I wasn't aware that this might come across negatively, arrogantly,
dictatorial, or something like that. Hope I didn't put off too many people.
I had
On Tue, 2011-09-27 at 12:21 +0200, Bjoern Michaelsen wrote:
and it seems unclear what the benefit vs. the pain pwrt.
when re-synching (around deleting old remote branches etc.) would be.
Given enough eyeballs all bugs are shallow. Having commits visible
some time before they hit master
On Tue, 2011-09-27 at 14:21 +0200, Stephan Bergmann wrote:
I wasn't aware that this might come across negatively, arrogantly,
Hey - sorry for rather an over-sharp response too; you weren't to know
that we as a team hadn't even discussed asking this of all developers
yet AFAIR.
On Tue, Sep 27, 2011 at 4:17 AM, Stephan Bergmann sberg...@redhat.com wrote:
On 09/27/2011 10:33 AM, Michael Meeks wrote:
No need to go creative here, IMO. With a default --disable-werror, I *hope*
it should suffice to just remind developers that they should --enable-werror
(the same way we
On 27.09.2011 10:33, Michael Meeks wrote:
Sure sure, so - I think Stephan has a point - that we ought to find
some way of enabling this for some set of people that can cope with it.
I suspect a good heuristic would be to have an 'auto' mode for the flag
that checks if you have git push
Just a friendly reminder that all developers should use --enable-werror
all the time.
It helps yourself (you find potential errors early), your fellow
developers (they don't need to fix your warnings for you), and our users
(via a more stable product).
(Different compilers tend to catch
Hi Stephan,
On Mon, 2011-09-26 at 08:41 +0200, Stephan Bergmann wrote:
Just a friendly reminder that all developers should use --enable-werror
all the time.
This is a nice idea of course :-) but some platforms spew errors
constantly beyond the control of the developer. IMHO it is best
On 09/26/2011 11:22 AM, Michael Meeks wrote:
Hi Stephan,
On Mon, 2011-09-26 at 08:41 +0200, Stephan Bergmann wrote:
Just a friendly reminder that all developers should use --enable-werror
all the time.
This is a nice idea of course :-) but some platforms spew errors
constantly beyond
On Mon, 2011-09-26 at 12:04 +0200, Stephan Bergmann wrote:
You mean, you let
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b24bd7a6ec714c74795cf417e35bd036303f3b9
hide a WaE... should be fixed properly when the issue is understood
through
Wait - is this the end of
I tried doing that, but it seems that my autogen flags made it so that I
was compiling some module unknown to me that was in 'build warning land'.
Unless we don't have modules living in such countries anymore, I won't
want to enable that option.
I see this flag as an aspirational goal let us fix
On Mon, 2011-09-26 at 11:40 +0100, Michael Meeks wrote:
We had a situation for several days with master giving tens of
thousands of warnings while building.
--enable-werror is a tricky thing alright given the different compilers,
even within the gcc family, or maybe especially within the gcc
Hi Michael,
On Mon, 26 Sep 2011 11:40:26 +0100
Michael Meeks michael.me...@novell.com
wrote:
The 'good old' days - where all work had to be done in a
branch, and then compiled on two platforms before merging is *gone*
(and -very- good riddance). I'll personally stamp on anything that
On 09/26/2011 01:15 PM, Marc-André Laverdière wrote:
I tried doing that, but it seems that my autogen flags made it so that I
was compiling some module unknown to me that was in 'build warning land'.
Unless we don't have modules living in such countries anymore, I won't
want to enable that
I think I wasn't clear.
I started doing things in LO when things were a lot harder than they
are now. I'm glad for all the community members who have been putting
order in this chaos. That experience lead me to believe that the policy
should be make it easy for the n00b.
When I tried using
21 matches
Mail list logo
