On Mon, 2013-01-07 at 18:12 +, Mark Shuttleworth wrote:
> On 01/07/2013 02:09 PM, Ted Gould wrote:
>
> >
> > The problem is that we're not talking about released versions, which
> > certainly should manage their API/ABI with proper SO numbers etc,
> > we're talking about development trunk. W
On Mon, 2013-01-07 at 18:13 +, Mark Shuttleworth wrote:
> On 01/07/2013 03:21 PM, Ted Gould wrote:
> >
> > I think that's the issue, you should be saying "We need to fix bug
> > 1234" not "Trunk was known broken, why aren't you focusing on my
> > problem RIGHT NOW."
>
>
> LEAN development tr
On Mon, 2013-01-07 at 16:42 +0100, Didier Roche wrote:
> Le 07/01/2013 16:21, Ted Gould a écrit :
> > I think that's the issue, you should be saying "We need to fix bug
> > 1234" not "Trunk was known broken, why aren't you focusing on my
> > problem RIGHT NOW." There might be other, higher prio
On 01/07/2013 03:21 PM, Ted Gould wrote:
> I think that's the issue, you should be saying "We need to fix bug
> 1234" not "Trunk was known broken, why aren't you focusing on my
> problem RIGHT NOW."
LEAN development treats a broken trunk as a stop-the-line problem, which
is exactly "fix it RIGHT N
On 01/07/2013 02:09 PM, Ted Gould wrote:
> The problem is that we're not talking about released versions, which
> certainly should manage their API/ABI with proper SO numbers etc,
> we're talking about development trunk. We've removed the ability to
> have a playground before committing to an API
Le 07/01/2013 17:03, Stephen M. Webb a écrit :
On 01/07/2013 10:39 AM, Didier Roche wrote:
You can take whatever other branch you want, like calling it "next foo
feature", then, using that one and having other
people and yourself branching from it, merge into it, writing tests,
experimenting w
On 01/07/2013 10:39 AM, Didier Roche wrote:
>>>
>>> You can take whatever other branch you want, like calling it "next foo
>>> feature", then, using that one and having other
>>> people and yourself branching from it, merge into it, writing tests,
>>> experimenting with other ppas containing it.
Le 07/01/2013 16:21, Ted Gould a écrit :
I think that's the issue, you should be saying "We need to fix bug
1234" not "Trunk was known broken, why aren't you focusing on my
problem RIGHT NOW." There might be other, higher priority work being
done. Or perhaps people are in the middle of longer
Le 07/01/2013 16:16, Stephen M. Webb a écrit :
On 01/07/2013 09:40 AM, Didier Roche wrote:
Le 07/01/2013 15:09, Ted Gould a écrit :
On Mon, 2013-01-07 at 07:35 +0100, Didier Roche wrote:
Also, that we have to do that because there is a bad history of committing to
ABI and API stability, remem
On Mon, 2013-01-07 at 15:50 +0100, Didier Roche wrote:
>
> I think you misread my first email or I didn't express properly, but I
> didn't put any blame on anyone or pointed that the feedback loop was
> inadequate, I just raised the issue that trunk was known (so it's not
> a question of awarenes
On 01/07/2013 09:40 AM, Didier Roche wrote:
> Le 07/01/2013 15:09, Ted Gould a écrit :
>> On Mon, 2013-01-07 at 07:35 +0100, Didier Roche wrote:
>>> Also, that we have to do that because there is a bad history of committing
>>> to ABI and API stability, remember that
>>> normally, in every normal
Le 07/01/2013 15:32, Ted Gould a écrit :
On Mon, 2013-01-07 at 07:40 +0100, Didier Roche wrote:
I second as well on the speed issue, please again, check within your
team with the responsible of those tools to see what they can do so
that the merge answer is way faster. I know that Jibel started
Le 07/01/2013 15:09, Ted Gould a écrit :
On Mon, 2013-01-07 at 07:35 +0100, Didier Roche wrote:
Also, that we have to do that because there is a bad history of
committing to ABI and API stability, remember that normally, in every
normal upstream project, such a breakage ask to change the soname
On Mon, 2013-01-07 at 07:40 +0100, Didier Roche wrote:
>
> I second as well on the speed issue, please again, check within your
> team with the responsible of those tools to see what they can do so
> that the merge answer is way faster. I know that Jibel started to have
> a look as well and it se
On Mon, 2013-01-07 at 07:35 +0100, Didier Roche wrote:
>
> Also, that we have to do that because there is a bad history of
> committing to ABI and API stability, remember that normally, in every
> normal upstream project, such a breakage ask to change the soname, and
> in this case, we will know
On 01/07/2013 06:40 AM, Didier Roche wrote:
>> Uhm, no. Stop blaming people when the tools are broken.
>>
>
> I agree with you here. Don't blame me for tools I'm not responsible
> for as well please, and rather, work with the PS QA team responsible
> for them to fix those.
>
Guys this is not abou
> Also, that we have to do that because there is a bad history of
> committing to ABI and API stability
That used to be true for Compiz but not true in recent history. Once a
release 0.9.N.0 is completed we try not to change the ABI or API. Though
0.9.9.0 for raring is not released yet so we re
Le 04/01/2013 20:33, Ted Gould a écrit :
On Fri, 2013-01-04 at 09:05 +0100, Didier Roche wrote:
Just back from vacations, I have the unpleasant surprise to notice
that unity fails to build in the staging ppa since 2012-12-19 and
that more than 7 merges were done in between without fixing it fir
Le 04/01/2013 20:38, Ted Gould a écrit :
On Fri, 2013-01-04 at 10:52 +0100, Didier Roche wrote:
- Nux broke its API and ABI and the build-dependency requirement
wasn't bumped on unity
- Compiz broke its API and ABI and the build-dependency requirement
wasn't bumped on unity
Please, for the 2
On Fri, 2013-01-04 at 10:52 +0100, Didier Roche wrote:
>
> - Nux broke its API and ABI and the build-dependency requirement
> wasn't bumped on unity
> - Compiz broke its API and ABI and the build-dependency requirement
> wasn't bumped on unity
>
> Please, for the 2 laters, please bump the requir
On Fri, 2013-01-04 at 09:05 +0100, Didier Roche wrote:
>
> Just back from vacations, I have the unpleasant surprise to notice
> that unity fails to build in the staging ppa since 2012-12-19 and that
> more than 7 merges were done in between without fixing it first (or
> reverting the faulty merge
Le 04/01/2013 09:05, Didier Roche a écrit :
Le 03/01/2013 04:38, Stephen M. Webb a écrit :
On 01/02/2013 09:43 PM, Daniel van Vugt wrote:
Did the compiler really give a warning? As far as I can tell, Nux, Unity and Compiz
already use "-Wall -Werror".
If mistakes still slip past gcc (and they
*cough* *cough* jhbuild! *cough*
;-)
On 4 January 2013 09:05, Didier Roche wrote:
> Le 03/01/2013 04:38, Stephen M. Webb a écrit :
>
> On 01/02/2013 09:43 PM, Daniel van Vugt wrote:
>
> Did the compiler really give a warning? As far as I can tell, Nux, Unity and
> Compiz already use "-Wall
Le 03/01/2013 04:38, Stephen M. Webb a écrit :
On 01/02/2013 09:43 PM, Daniel van Vugt wrote:
Did the compiler really give a warning? As far as I can tell, Nux, Unity and Compiz
already use "-Wall -Werror".
If mistakes still slip past gcc (and they do) then I recommend making your code
compat
On 01/02/2013 09:43 PM, Daniel van Vugt wrote:
> Did the compiler really give a warning? As far as I can tell, Nux, Unity and
> Compiz already use "-Wall -Werror".
>
> If mistakes still slip past gcc (and they do) then I recommend making your
> code compatible with clang because it gives
> more
Did the compiler really give a warning? As far as I can tell, Nux, Unity
and Compiz already use "-Wall -Werror".
If mistakes still slip past gcc (and they do) then I recommend making
your code compatible with clang because it gives more and better
warnings/errors. We've done this for lp:compiz
On 22/12/12 05:42, Sam Spilsbury wrote:
> Be careful when making changes like these, especially when the
> compiler is warning that you are no longer using data you once did. In
> addition, when doing refactoring, please try and do either of the
> following:
>
> 1. Add tests for the unit under test
Hey All,
I know that refactoring our existing code to improve readability and
design is important, but I've seen a few regressions slip through our
projects lately because we've been doing it too aggressively. For
example, I just spent the last few days scratching my head trying to
figure out why
28 matches
Mail list logo
