On Sun, Apr 29, 2007 at 07:21:34PM +0200, Uwe Stöhr wrote:
> I'm very displeased by the renamng actions you did the last week. This was 
> absolutely unnecessary, we just have released a second beta and our 
> exercise is to fix the remaining bugs to be able to release LyX 1.5.0.

The idea was to ease maintanance of a stable and a development branch
when basically all files change.

> Sorry, but why did you mean we have to change our complete infrastructure 
> while we are close to a stable release?

Hunt the archive. Doing the renamings _now_ was discussed and approved
by several people. I don't remember your opposition, but memory is
failing me more often than I wish...

> Of course the renaming .C -> .cpp 
> might have advantages and the merging is in general also a good idea but 
> wasn't that pressing. There was no need to change this at this state of 
> development. Further renaming can be done as soon as a LyX 1.6 development 
> trunk has been created.

If the renamining had been done in early 1.6.0, no 1.6.0 patach would
have been applicable to 1.5.x and vice versa.

> I'm sure that we have introduced new bugs and problems - the third beta 
> will tell.

We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
 
> I the meantime I faced lots of compile problems so that we lost one week of 
> development as our mst active bug fixers couldn't work. We now also lost 
> the SVN version history that was very important to be able to fix bugs.

The history is not lost, it's just more difficult to access (which is
not nice, but certainly not critical). To see the old paragraph.C
related messages up to revision 16000 type

        svn log svn+ssh://[EMAIL PROTECTED]/lyx/lyx-devel/trunk/src/[EMAIL 
PROTECTED]

[of course you might need to adjust the 'poenitz' or guess my
password. The first option might be less work...]

> So stop these actions now! If you really can't wait and want to do further 
> renaming, discuss this and create a new brach where you can play if 
> necessary.

You miss the point and I see no reason to stop at a point where more
than 90% of the work is done.

Andre'

Reply via email to