Jan Nieuwenhuizen wrote: > Op vrijdag 06-11-2009 om 13:31 uur [tijdzone +0100], schreef Juergen > Schmidt: >> Jan Nieuwenhuizen wrote: >> > Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen >> > Schmidt: > >> > patches were removed [or reverted] again. >> do you know the reasons for that? > > I don't know, there must a bug in openoffice.org's "commit" command?
No, I was "guilty". I made the changes in the CWS but had problems again to compile it on all platforms with all three #define variants. As I wanted to get my CWS into 3.2, I finally decided to remove the "experimental" stuff from it and come back to that later in another CWS. Sorry, I forgot to notify you about that. > When I commit code to Go-oo, chances are that a binary will be built > from them and shipped to users within a week. Sometimes within hours. > Also, upstream often did [does?] not build ootb, and it's impossible for > me to fix the build within a reasonable time frame [ie: hours]. I > can fix the go-oo build within an hour if it's broken, if someone > doesn't beat me to it ;-) You miss Jürgen's point: it's fine that your code compiles in your go-oo code base, but that does't necessarily mean that it does the same in the upstream code base. We always have problems integrating larger patches that have been created on older milestones, and from my own experience I had this in both layout CWS I have worked on together with you. Don't get me wrong, that's not a complaint, just a fact. I hope you remember that I tried to support you with integrating the code as good as I could, but I wonder whether I can justify that effort for each layouting contribution. > In my case with layout dialogs, it allowed me to get OO.o binaries > shipped with dialogs enabled for more than a year now...while upstream > cannot even build them yet? Possibly the fresh layoutdialogs3 builds, > let's all pray it won't have bits removed upon/after integration and > 'commit' takes less than half a year this time. You should remember that your code didn't compile on Windows and Solaris at all and I had a hard time getting that fixed (remember the namespace trouble on Windows?). And every new change has the risk to break the build again if you only compile and test it on Linux. >> I would to like to see at least or expect a complete picture how we want >> handle this in the future. > > That's grand, please send a patch! Well, what Jürgen asked for is not doable in code. He asks for the perspective: does it make sense to continue with this approach if you take the number of converted dialogs per man month / year and compare it with the number of existing dialogs? In the same time we perhaps could have re-written more dialogs from scratch, using your layout code in the toolkit module, perhaps with another API that does not sacrifice modularization in favor of trying to keep the old dialog code as much as possible. [Explanation for my modularization concerns: we both already found out that your current approach will either move more controls and dialogs into the toolkit module (e.g. you had moved SvxLanguageBox into toolkit) or creates the need to export the layout core so that the controls can stay in their library. Perhaps a component based approach (I didn't say UNO component, just component ;-)) would be better from a modularization POV.] These are only some thoughts, no verdict. I never had enough time to dive deep enough into your code to decide if my concerns are justified or just paranoia. It would be nice to develop a common understanding about that. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
