Trunk is stable again !

[Emmanuel Lecharny <el...@apache.org>]

Pfewww... It took me more than one day to stabilize the trunk again.

Why so long ? Simple :
- I don't have my fast MBP, and I had to restore my dev env on 2 machines
(at home and at office). That only is a painful and slow process, with
eclipse, java, maven, subclipse installation (not to mention an Ubuntu
update)
- on those two machines, compiling the full server takes more than 20
minutes...
- At first, I thought I could find the issue by debugging the code. How vain
is this ... But certainly cost half a day !
- I then had to find the revision that was working. It took me something
like 10 reverts and full builds to get this revision, and I had to go back
30 revisions, then 10 revs forward.
- Again, I tried to take a shortcut by moving 10 revs forward, and fix the
issue. Vain, I said, vain...
- so back to painful revert and moving forward one revision after the other
one, and removing what was wrong.

At the end, I was bale to find what was wrong, and to keep it out of our
path :
- first a small issue with conccurent test (taht was really easy to find and
fix)
- second a brutal modification done by me that imapcted the whole server
with many strange errors (basically,  I removed the AlteredEntry field from
the ModificationOperationContext class, as we already have a ModifiedEntry
in an abstract Class. bad bad move...

Anyway, this is it !

let's move forward !
(btw, my MBP is just ready, I have to go back and get it.)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Trunk is stable again !

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Works fine for me too.

Congrats Emmanuel!


On 23 juin 2010, at 19:19, Stefan Seelmann wrote:

> I can confirm, trunk build fine now.
> 
> Thanks Emmanuel!
> 
> On 6/23/10 6:53 PM, Emmanuel Lecharny wrote:
>> Pfewww... It took me more than one day to stabilize the trunk again.
>> 
>> Why so long ? Simple :
>> - I don't have my fast MBP, and I had to restore my dev env on 2 machines (at home and at office). That only is a painful and slow process, with eclipse, java, maven, subclipse installation (not to mention an Ubuntu update)
>> - on those two machines, compiling the full server takes more than 20 minutes...
>> - At first, I thought I could find the issue by debugging the code. How vain is this ... But certainly cost half a day !
>> - I then had to find the revision that was working. It took me something like 10 reverts and full builds to get this revision, and I had to go back 30 revisions, then 10 revs forward.
>> - Again, I tried to take a shortcut by moving 10 revs forward, and fix the issue. Vain, I said, vain...
>> - so back to painful revert and moving forward one revision after the other one, and removing what was wrong.
>> 
>> At the end, I was bale to find what was wrong, and to keep it out of our path :
>> - first a small issue with conccurent test (taht was really easy to find and fix)
>> - second a brutal modification done by me that imapcted the whole server with many strange errors (basically,  I removed the AlteredEntry field from the ModificationOperationContext class, as we already have a ModifiedEntry in an abstract Class. bad bad move...
>> 
>> Anyway, this is it !
>> 
>> let's move forward !
>> (btw, my MBP is just ready, I have to go back and get it.)
>> 
>> -- 
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com <http://www.iktek.com>
> 

Re: Trunk is stable again !

[Stefan Seelmann <se...@apache.org>]

I can confirm, trunk build fine now.

Thanks Emmanuel!

On 6/23/10 6:53 PM, Emmanuel Lecharny wrote:
> Pfewww... It took me more than one day to stabilize the trunk again.
>
> Why so long ? Simple :
> - I don't have my fast MBP, and I had to restore my dev env on 2 
> machines (at home and at office). That only is a painful and slow 
> process, with eclipse, java, maven, subclipse installation (not to 
> mention an Ubuntu update)
> - on those two machines, compiling the full server takes more than 20 
> minutes...
> - At first, I thought I could find the issue by debugging the code. 
> How vain is this ... But certainly cost half a day !
> - I then had to find the revision that was working. It took me 
> something like 10 reverts and full builds to get this revision, and I 
> had to go back 30 revisions, then 10 revs forward.
> - Again, I tried to take a shortcut by moving 10 revs forward, and fix 
> the issue. Vain, I said, vain...
> - so back to painful revert and moving forward one revision after the 
> other one, and removing what was wrong.
>
> At the end, I was bale to find what was wrong, and to keep it out of 
> our path :
> - first a small issue with conccurent test (taht was really easy to 
> find and fix)
> - second a brutal modification done by me that imapcted the whole 
> server with many strange errors (basically,  I removed the 
> AlteredEntry field from the ModificationOperationContext class, as we 
> already have a ModifiedEntry in an abstract Class. bad bad move...
>
> Anyway, this is it !
>
> let's move forward !
> (btw, my MBP is just ready, I have to go back and get it.)
>
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>

Re: Trunk is stable again !

[Kiran Ayyagari <ka...@apache.org>]

thanks Emmanuel, I knew it was hard and sorry being away

Kiran Ayyagari

On Wed, Jun 23, 2010 at 10:23 PM, Emmanuel Lecharny
<el...@apache.org> wrote:
> Pfewww... It took me more than one day to stabilize the trunk again.
>
> Why so long ? Simple :
> - I don't have my fast MBP, and I had to restore my dev env on 2 machines
> (at home and at office). That only is a painful and slow process, with
> eclipse, java, maven, subclipse installation (not to mention an Ubuntu
> update)
> - on those two machines, compiling the full server takes more than 20
> minutes...
> - At first, I thought I could find the issue by debugging the code. How vain
> is this ... But certainly cost half a day !
> - I then had to find the revision that was working. It took me something
> like 10 reverts and full builds to get this revision, and I had to go back
> 30 revisions, then 10 revs forward.
> - Again, I tried to take a shortcut by moving 10 revs forward, and fix the
> issue. Vain, I said, vain...
> - so back to painful revert and moving forward one revision after the other
> one, and removing what was wrong.
>
> At the end, I was bale to find what was wrong, and to keep it out of our
> path :
> - first a small issue with conccurent test (taht was really easy to find and
> fix)
> - second a brutal modification done by me that imapcted the whole server
> with many strange errors (basically,  I removed the AlteredEntry field from
> the ModificationOperationContext class, as we already have a ModifiedEntry
> in an abstract Class. bad bad move...
>
> Anyway, this is it !
>
> let's move forward !
> (btw, my MBP is just ready, I have to go back and get it.)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>