Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Am Freitag, 16. Dezember 2011 schrieb Ariel Constenla-Haile arie...@apache.org: Hi Eric, On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote: Question: shall I copy the whole trunk on the branch or only trunk/main? Very good question :-) In fact, I don't know how to create a new branch with svn. Is there a wiki page explaining that ? I don't use svn myself (I use git-svn), but I've found http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create the command will be: $ svn copy \ https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \ https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild If I only copy trunk/main I see Armin copied the whole trunk, but in this case may be I can omit the extras and ext_sources subrepos. i would suggest to copy trunk completely to be consistent and to have everything in place. As Dennis pointed out it's not a big overhead and only changed files need space. And the extras directories with the translation contains makefiles as well. They have to be converted also over time ;-) Juergen Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
On 17/12/11 06:27, Ariel Constenla-Haile wrote: This way we can use branches/gbuild to create further feature branches for gbuild conversion that can not be done on trunk directly (here I can imagine the desktop module, for example). errm, yes, converting the desktop module on master (not on a branch) turned out to be quite a disaster at LO, so... branches are good :)
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi there, On Sat, Nov 26, 2011 at 08:33:47AM +0100, eric b wrote: It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). I'm not sure if the gnumake4 integration should be moved to a feature branch. Please use a feature branch I'm going to create a feature branch, named gbuild (I won't follow the apache-id naming schema, because this was not my work, nor am I going to be the only one committing code to it). I'll apply the set of patches here http://people.apache.org/~arielch/gbuild-13-12-2011/ except http://people.apache.org/~arielch/gbuild-13-12-2011/-gbuild-convert-lingucomponent.patch that didn't get very well on Windows. Question: shall I copy the whole trunk on the branch or only trunk/main? Regards -- Ariel Constenla-Haile La Plata, Argentina pgpbOEymlCDN8.pgp Description: PGP signature
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hello Ariel, Le 16 déc. 11 à 12:31, Ariel Constenla-Haile a écrit : Hi there, On Sat, Nov 26, 2011 at 08:33:47AM +0100, eric b wrote: Please use a feature branch I'm going to create a feature branch, named gbuild (I won't follow the apache-id naming schema, because this was not my work, nor am I going to be the only one committing code to it). Ok, good idea ! I'll apply the set of patches here http://people.apache.org/ ~arielch/gbuild-13-12-2011/ except http://people.apache.org/~arielch/gbuild-13-12-2011/-gbuild- convert-lingucomponent.patch that didn't get very well on Windows. Ok Question: shall I copy the whole trunk on the branch or only trunk/ main? Very good question :-) In fact, I don't know how to create a new branch with svn. Is there a wiki page explaining that ? In the old OOo times, I remember we used cws_create, but should be one hidden svn command imho. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi Eric, On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote: Question: shall I copy the whole trunk on the branch or only trunk/main? Very good question :-) In fact, I don't know how to create a new branch with svn. Is there a wiki page explaining that ? I don't use svn myself (I use git-svn), but I've found http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create the command will be: $ svn copy \ https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \ https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild If I only copy trunk/main I see Armin copied the whole trunk, but in this case may be I can omit the extras and ext_sources subrepos. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpMenzjFSTi2.pgp Description: PGP signature
RE: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
It doesn't matter too much how much you copy into a branch, apart from it creating larger working copy. But you don't need to check out the entire working copy of the branch if you don't want. You might need it to do builds though. Ask Armin. SVN uses a copy-on-write technique, so only the files you change in the branch take up much space on the server. (And if they are modified on the trunk, you won't get the new one but a copy of the old one will still appear on the branch, as I understand it. I've no idea whether linking can be used to keep those parts synchronized instead.) -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Friday, December 16, 2011 05:05 To: ooo-dev@incubator.apache.org Subject: Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces) Hi Eric, On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote: Question: shall I copy the whole trunk on the branch or only trunk/main? Very good question :-) In fact, I don't know how to create a new branch with svn. Is there a wiki page explaining that ? I don't use svn myself (I use git-svn), but I've found http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create the command will be: $ svn copy \ https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \ https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild If I only copy trunk/main I see Armin copied the whole trunk, but in this case may be I can omit the extras and ext_sources subrepos. Regards -- Ariel Constenla-Haile La Plata, Argentina smime.p7s Description: S/MIME cryptographic signature
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi Ariel; --- Ven 16/12/11, Ariel Constenla-Haile arie...@apache.org ha scritto: Hi there, I'm going to create a feature branch, named gbuild (I won't follow the apache-id naming schema, because this was not my work, nor am I going to be the only one committing code to it). And as I said I'll gladly move there and check the FreeBSD required changes. I'll apply the set of patches here http://people.apache.org/~arielch/gbuild-13-12-2011/ except http://people.apache.org/~arielch/gbuild-13-12-2011/-gbuild-convert-lingucomponent.patch that didn't get very well on Windows. FWIW, I noticed there is this change on the gnumake4 branch: vcl2gnumake: #i116588# move vcl to gbuild (step 1, linux) http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8 but it's not on your list, maybe I missed it. Question: shall I copy the whole trunk on the branch or only trunk/main? main is enough. cheers, Pedro.
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi Pedro, On Fri, Dec 16, 2011 at 08:10:55PM -0800, Pedro Giffuni wrote: I'm going to create a feature branch, named gbuild (I won't follow the apache-id naming schema, because this was not my work, nor am I going to be the only one committing code to it). And as I said I'll gladly move there and check the FreeBSD required changes. I'll apply the set of patches here http://people.apache.org/~arielch/gbuild-13-12-2011/ except http://people.apache.org/~arielch/gbuild-13-12-2011/-gbuild-convert-lingucomponent.patch that didn't get very well on Windows. FWIW, I noticed there is this change on the gnumake4 branch: vcl2gnumake: #i116588# move vcl to gbuild (step 1, linux) http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8 but it's not on your list, maybe I missed it. this is rather old, and integrated into OOO340: http://hg.services.openoffice.org/OOO340/rev/373f4b04c6b8 That cws was fully integrated: http://hg.services.openoffice.org/OOO340/rev/18597186a506 Question: shall I copy the whole trunk on the branch or only trunk/main? main is enough. I'm still uncertain about the layout. I do not want to use my apache-id, this is not my work (well, I converted some modules to gbuild, but it's the main work from Mathias Bauer, Michael Stahl, et. al. - that info is kept in the commit messages), and I'm not the only one to commit code in that branch (I don't do MacOS, FreeBDS, and my Win knowledge is rather poor, so this has to be a team work). May be I can use: branches/gbuild/gbuild1 gbuild being like the id. This way we can use branches/gbuild to create further feature branches for gbuild conversion that can not be done on trunk directly (here I can imagine the desktop module, for example). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpMnRFM1Gmxi.pgp Description: PGP signature
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
--- Sab 17/12/11, Ariel Constenla-Haile arie...@apache.org ha scritto: ... Data: Sabato 17 dicembre 2011, 00:27 Hi Pedro, On Fri, Dec 16, 2011 at 08:10:55PM -0800, Pedro Giffuni wrote: I'm going to create a feature branch, named gbuild (I won't follow the apache-id naming schema, because this was not my work, nor am I going to be the only one committing code to it). And as I said I'll gladly move there and check the FreeBSD required changes. I'll apply the set of patches here http://people.apache.org/~arielch/gbuild-13-12-2011/ except http://people.apache.org/~arielch/gbuild-13-12-2011/-gbuild-convert-lingucomponent.patch that didn't get very well on Windows. FWIW, I noticed there is this change on the gnumake4 branch: vcl2gnumake: #i116588# move vcl to gbuild (step 1, linux) http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8 but it's not on your list, maybe I missed it. this is rather old, and integrated into OOO340: http://hg.services.openoffice.org/OOO340/rev/373f4b04c6b8 That cws was fully integrated: http://hg.services.openoffice.org/OOO340/rev/18597186a506 Question: shall I copy the whole trunk on the branch or only trunk/main? main is enough. I'm still uncertain about the layout. I do not want to use my apache-id, this is not my work (well, I converted some modules to gbuild, but it's the main work from Mathias Bauer, Michael Stahl, et. al. - that info is kept in the commit messages), and I'm not the only one to commit code in that branch (I don't do MacOS, FreeBDS, and my Win knowledge is rather poor, so this has to be a team work). May be I can use: branches/gbuild/gbuild1 Or branches/cws-integration/gnumake4 It doesnt really matter, we will remove it when the code is integrated. ;) Pedro.
Re: [Code] strategy for child works spaces
Hi Eric, On 14.12.2011 23:45, eric b wrote: Hello, Looks like some files are missing (svgclippathnode.hxx here) : truc:~/Desktop/apache_ooo/alg/svgreplacement/main/svgio ericb$ make -sr cp: /Users/ericb/Desktop/apache_ooo/alg/svgreplacement/main/svgio/inc/svgio/svgreader/svgclippathnode.hxx: No such file or directory Sorry, some files were missing. I'll have to add the wntmsci12 dirs to the stuff to be ignored on status, svn status does not give a good overview on windows builds. Sorry, added and comitted. Argh. Thanks, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi *, my approach to replacing Svg in 3.4 with an internal interpreter makes good progress. It's available on [1], some people already took a look. It's stable and I added quite some Svg features the last days. If someone wishes to test there have already been links to built versions in this tread (thanks to eric b). Since it's part of IP clearance (and replacement) I suggest to integrate it back to the main trunk in the next 2-3 weeks. This will ensure broader testing with the upcoming nightly builds and enough time to work on evtl. upcoming tasks, too. [1] https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement On 02.12.2011 11:55, Armin Le Grand wrote: Salut eric, [..] Feel free to fetch and build the first version of Svg replacement on https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement. Win and mac version built, linux not yet. Looking forward to Your findings, esp. bugs of course :-) [..] Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Le 14 déc. 11 à 18:33, Armin Le Grand a écrit : Hi *, Hello Armin, my approach to replacing Svg in 3.4 with an internal interpreter makes good progress. It's available on [1], some people already took a look. It's stable and I added quite some Svg features the last days. If someone wishes to test there have already been links to built versions in this tread (thanks to eric b). I'll build new versions with the last changes you did. Mac OS X will be available tomorrow (build started), and Windows, probably friday (en-US, de and fr for both). + I'll try to build some debs too on my i7@920. People interested can contact me for the download. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hello, Looks like some files are missing (svgclippathnode.hxx here) : truc:~/Desktop/apache_ooo/alg/svgreplacement/main/svgio ericb$ make -sr cp: /Users/ericb/Desktop/apache_ooo/alg/svgreplacement/main/svgio/inc/ svgio/svgreader/svgclippathnode.hxx: No such file or directory Thanks, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Eric, On 05.12.2011 18:40, eric b wrote: Hi Armin, Le 5 déc. 11 à 16:58, Armin Le Grand a écrit : Hi Eric, On 05.12.2011 16:22, Armin Le Grand wrote: Hi eric, [..] Ah okay, have not done exactly that yet. I mostly DD Svgs to a freshly opened Draw/Impress, save and reload it (also Writer). I have to check what happens when saving as Svg. Currently my workspace is corrupt (svn cleanup saying to use svn cleanup :-(), so I'll need a moment... :-/ Have now opened SVG directly from start screen - I get a Draw with centered Svg graphic object. Saved as, given a name - saved as *.odg Reloaded - all works, Svg is in reloaded file Tried to Save as and choosing SVG - not possible, SVG is not in the selection. FYI, On Mac OS X, I got it. The process: Drag an .svg file over the startcenter - it opens a draw page, containing the centered .svg. File - Export ... Select .svg Got a screenshot : http://ftp.educoo.org/home/ApacheOpenOffice.org/native_svg/save_as_svg.png Very strange. Thhis is not possible with Win, I do not know about Linux versions. Hmmm. Thus I guess You used 'export...', there You can select SVG (and to only export selected objects, but I did not) - Creates a SVG export file containing the Svg as Bitmap (image x=3533 y=6566 width=13934 height=16567 xlink:href=data:image/png;base64, iVBORw0KGgoNSUhEUgAAAogAAAMDCAYhSeQVCXBIWXMAA). Not perfect, but working (using the already existing Svg exporter). Ok Hmm, looks pretty complete to me, Some other tests I did : 1) I downloaded the full OpenClipart archive, and open a lot of .svg (no, I didn't open all ;) . No problem so far. Seems to work very well, at least for all the files I opened. Good news. It seems to pay to base an import systematically on the spec... 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Please send the example, a screenshot and mark where I should zoom. I have a guess, but will need to play around with it. Other remarks : one people wrote me the import works fine with the penguin, but there were some glitches. Excepted the gradient, I didn't see anything wrong. Do you confirm ? I saw that in the comments, maybe the same issue... embedding the Svg when exporting Svg would of course be better, but it's existing Svg export code and I will have to check first if this would be possible... Ok. anyway, I confirm it works very well already !! (Windows build is slow as hell ... maybe tomorrow morning, if no other breakage occurs in meantime) Regards, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi Eric, On 02.12.2011 21:25, eric b wrote: Hi, Answering to myself, build completed (some hacks mandatory, mostly berkeleydb and rhino broken) on Mac OS X 10.4, for en-US, de and fr locales. They should work on all Mac OS X Intel, from 10.4 to 10.7 Hmm. I resynched to trunk on friday noon and could build win and mac without problems for svgreplacement. I'm not sure what is going wrong on Your side. On win I use --with-cl-home=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC \ --with-jdk-home=/cygdrive/c/Program Files (x86)/Java/jdk1.6.0_27 \ --with-mspdb-path=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/Common7/IDE \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1/Bin \ --with-asm-home=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC \ --with-csc-path=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC/SDK/v3.5 \ --with-ant-home=/cygdrive/c/ant \ --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2; \ --enable-pch \ --enable-dbgutil \ --disable-atl \ --disable-activex \ --disable-binfilter \ --disable-copyleft \ --without-junit HTH! Is there a place I could upload those builds for testing purpose ? On the testing side now ... first test : opening the first .svg I found on the web - no problem. Second test : .svg export does nothing (reopen the exported .svg gives a white page) Just en passant, I'd suggest to rename the preferences folder, e.g. : ~/Library/Application Support/ApacheOpenOffice/ on Mac OS X to avoid confusion with the previous 3.3.x What do you think ? Thanks in advance, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi Eric, On 02.12.2011 21:25, eric b wrote: Hi, [..] ... first test : opening the first .svg I found on the web - no problem. Second test : .svg export does nothing (reopen the exported .svg gives a white page) OOps, I checked exporting. What exactly are You doing? Selecting the object to export (a embedded Svg), then using Export from the menu, specifying Svg and activating the 'Only Selection' switch in the export dialog...? Please explain in detail, different things happen internally when choosing different ways to export. [..] Thanks in advance, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Le 5 déc. 11 à 10:47, Armin Le Grand a écrit : Hi Eric, Hi Armin, On 02.12.2011 21:25, eric b wrote: Hi, [..] ... first test : opening the first .svg I found on the web - no problem. Second test : .svg export does nothing (reopen the exported .svg gives a white page) OOps, I checked exporting. What exactly are You doing? What I did : Open an .svg file = opens in Draw. Save it as the same_name2.svg Open it again - empty page. Selecting the object to export (a embedded Svg), Select or not the object does nothing more. then using Export from the menu, ok specifying Svg and activating the 'Only Selection' switch in the export dialog...? ok (I modified nothing in the export dialog box, which had autpmatic extension by default) Please explain in detail, different things happen internally when choosing different ways to export. I tried. Please tell me whether you need more information. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi eric, On 05.12.2011 14:35, eric b wrote: Le 5 déc. 11 à 10:47, Armin Le Grand a écrit : Hi Eric, Hi Armin, On 02.12.2011 21:25, eric b wrote: Hi, [..] ... first test : opening the first .svg I found on the web - no problem. Second test : .svg export does nothing (reopen the exported .svg gives a white page) OOps, I checked exporting. What exactly are You doing? What I did : Open an .svg file = opens in Draw. Save it as the same_name2.svg Open it again - empty page. Ah okay, have not done exactly that yet. I mostly DD Svgs to a freshly opened Draw/Impress, save and reload it (also Writer). I have to check what happens when saving as Svg. Currently my workspace is corrupt (svn cleanup saying to use svn cleanup :-(), so I'll need a moment... Selecting the object to export (a embedded Svg), Select or not the object does nothing more. then using Export from the menu, ok specifying Svg and activating the 'Only Selection' switch in the export dialog...? ok (I modified nothing in the export dialog box, which had autpmatic extension by default) Please explain in detail, different things happen internally when choosing different ways to export. I tried. Please tell me whether you need more information. You tried and...what? Was there something or not? I guess not, but want to make sure :-) Regards, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi Eric, On 05.12.2011 16:22, Armin Le Grand wrote: Hi eric, [..] Ah okay, have not done exactly that yet. I mostly DD Svgs to a freshly opened Draw/Impress, save and reload it (also Writer). I have to check what happens when saving as Svg. Currently my workspace is corrupt (svn cleanup saying to use svn cleanup :-(), so I'll need a moment... Have now opened SVG directly from start screen - I get a Draw with centered Svg graphic object. Saved as, given a name - saved as *.odg Reloaded - all works, Svg is in reloaded file Tried to Save as and choosing SVG - not possible, SVG is not in the selection. Thus I guess You used 'export...', there You can select SVG (and to only export selected objects, but I did not) - Creates a SVG export file containing the Svg as Bitmap (image x=3533 y=6566 width=13934 height=16567 xlink:href=data:image/png;base64, iVBORw0KGgoNSUhEUgAAAogAAAMDCAYhSeQVCXBIWXMAA). Not perfect, but working (using the already existing Svg exporter). Hmm, looks pretty complete to me, embedding the Svg when exporting Svg would of course be better, but it's existing Svg export code and I will have to check first if this would be possible... Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi Armin, Le 5 déc. 11 à 16:58, Armin Le Grand a écrit : Hi Eric, On 05.12.2011 16:22, Armin Le Grand wrote: Hi eric, [..] Ah okay, have not done exactly that yet. I mostly DD Svgs to a freshly opened Draw/Impress, save and reload it (also Writer). I have to check what happens when saving as Svg. Currently my workspace is corrupt (svn cleanup saying to use svn cleanup :-(), so I'll need a moment... :-/ Have now opened SVG directly from start screen - I get a Draw with centered Svg graphic object. Saved as, given a name - saved as *.odg Reloaded - all works, Svg is in reloaded file Tried to Save as and choosing SVG - not possible, SVG is not in the selection. FYI, On Mac OS X, I got it. The process: Drag an .svg file over the startcenter - it opens a draw page, containing the centered .svg. File - Export ... Select .svg Got a screenshot : http://ftp.educoo.org/home/ApacheOpenOffice.org/ native_svg/save_as_svg.png Thus I guess You used 'export...', there You can select SVG (and to only export selected objects, but I did not) - Creates a SVG export file containing the Svg as Bitmap (image x=3533 y=6566 width=13934 height=16567 xlink:href=data:image/png;base64, iVBORw0KGgoNSUhEUgAAAogAAAMDCAYhSeQVCXBIWXMAA). Not perfect, but working (using the already existing Svg exporter). Ok Hmm, looks pretty complete to me, Some other tests I did : 1) I downloaded the full OpenClipart archive, and open a lot of .svg (no, I didn't open all ;) . No problem so far. Seems to work very well, at least for all the files I opened. 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Other remarks : one people wrote me the import works fine with the penguin, but there were some glitches. Excepted the gradient, I didn't see anything wrong. Do you confirm ? embedding the Svg when exporting Svg would of course be better, but it's existing Svg export code and I will have to check first if this would be possible... Ok. anyway, I confirm it works very well already !! (Windows build is slow as hell ... maybe tomorrow morning, if no other breakage occurs in meantime) Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
On Mon, 5 Dec 2011 18:40:14 +0100 eric b eric.bach...@free.fr wrote: snip 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Do you mean that the continuous tone gradient resolves into dicrete tonal steps? -- Rory O'Farrell ofarr...@iol.ie
Re: [Code] strategy for child works spaces
Hi, Le 5 déc. 11 à 18:51, Rory O'Farrell a écrit : On Mon, 5 Dec 2011 18:40:14 +0100 eric b eric.bach...@free.fr wrote: snip 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Do you mean that the continuous tone gradient resolves into dicrete tonal steps? Something lke that, yes. In applied optics (my job in the real life) the name is aliasing, but I'm unsure this is what we observe here. If you want to verify, I can provide a link to download Mac OS X Intel build, either german, english or french (apologies, Windows is not finished yet). Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
On Mon, 5 Dec 2011 18:57:01 +0100 eric b eric.bach...@free.fr wrote: Le 5 déc. 11 à 18:51, Rory O'Farrell a écrit : snip Do you mean that the continuous tone gradient resolves into dicrete tonal steps? Something lke that, yes. In applied optics (my job in the real life) the name is aliasing, but I'm unsure this is what we observe here. I think this is what in graphics would be called a grey scale; I'm just trying to help the description of the result, which may strike a chord in some else's mind of some problem they have come across before. If you want to verify, I can provide a link to download Mac OS X Intel build, either german, english or french (apologies, Windows is not finished yet). I'm not into low level code, due to time constraints. My free time is given as a Volunteer on the Forum, where I am one of the top posters. -- Rory O'Farrell ofarr...@iol.ie
SVG Image Rasterization (was RE: [Code] strategy for child works spaces)
Without looking, but based on how Eric described the effect, I believe it is aliasing on the monitor if not elsewhere in the pipeline. Especially if it shows a Moiré pattern. There are an amazing number of places in the rendering pipeline where something could be off, especially if there is any intermediate resampling. It is a function of rasterization of the image. - Dennis PS: The funniest case for me is when I attempt to take pictures of my computer LCD display with my digital camera. The LCD preview on the back of the camera shows unbelievably bad Moiré (think of the number of times resampling, especially down-sampling, is being done), but if I zoom into the image on the camera's LCD display I find that the 10 Mpixel digital image is often -- not always -- clean and without much aliasing, if any. (My manual anti-aliasing procedure is to defocus the image slightly.) -Original Message- From: eric b [mailto:eric.bach...@free.fr] Sent: Monday, December 05, 2011 09:57 To: ooo-dev@incubator.apache.org Subject: Re: [Code] strategy for child works spaces Hi, Le 5 déc. 11 à 18:51, Rory O'Farrell a écrit : On Mon, 5 Dec 2011 18:40:14 +0100 eric b eric.bach...@free.fr wrote: snip 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Do you mean that the continuous tone gradient resolves into dicrete tonal steps? Something lke that, yes. In applied optics (my job in the real life) the name is aliasing, but I'm unsure this is what we observe here. If you want to verify, I can provide a link to download Mac OS X Intel build, either german, english or french (apologies, Windows is not finished yet). Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: SVG Image Rasterization (was RE: [Code] strategy for child works spaces)
On Mon, Dec 5, 2011 at 5:29 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Without looking, but based on how Eric described the effect, I believe it is aliasing on the monitor if not elsewhere in the pipeline. Especially if it shows a Moiré pattern. If it is a gradient, and it happens at high zooms, then this could be banding. http://en.wikipedia.org/wiki/Colour_banding -Rob There are an amazing number of places in the rendering pipeline where something could be off, especially if there is any intermediate resampling. It is a function of rasterization of the image. - Dennis PS: The funniest case for me is when I attempt to take pictures of my computer LCD display with my digital camera. The LCD preview on the back of the camera shows unbelievably bad Moiré (think of the number of times resampling, especially down-sampling, is being done), but if I zoom into the image on the camera's LCD display I find that the 10 Mpixel digital image is often -- not always -- clean and without much aliasing, if any. (My manual anti-aliasing procedure is to defocus the image slightly.) -Original Message- From: eric b [mailto:eric.bach...@free.fr] Sent: Monday, December 05, 2011 09:57 To: ooo-dev@incubator.apache.org Subject: Re: [Code] strategy for child works spaces Hi, Le 5 déc. 11 à 18:51, Rory O'Farrell a écrit : On Mon, 5 Dec 2011 18:40:14 +0100 eric b eric.bach...@free.fr wrote: snip 2) Opening an .svg containing gradients, I played with the zoom, until a big value, and the only strange issue I saw was sort of spatial filtering, say spectral effect, like aliasing in the areas containing the gradient. After some tries, the phenomen occurs every times for some well defined zoom values (sorry if I'm not clear). Do you mean that the continuous tone gradient resolves into dicrete tonal steps? Something lke that, yes. In applied optics (my job in the real life) the name is aliasing, but I'm unsure this is what we observe here. If you want to verify, I can provide a link to download Mac OS X Intel build, either german, english or french (apologies, Windows is not finished yet). Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Am 12/02/2011 09:25 PM, schrieb eric b: Just en passant, I'd suggest to rename the preferences folder, e.g. : ~/Library/Application Support/ApacheOpenOffice/ on Mac OS X to avoid confusion with the previous 3.3.x What do you think ? Of course a good thing. But I think it's a logical step as OOo is now done in any form of appearance in the product. IMHO this applies also for the strings in the basename for the install and user directory. Marcus
Re: [Code] strategy for child works spaces
Hi, Le 3 déc. 11 à 11:09, Marcus (OOo) a écrit : Am 12/02/2011 09:25 PM, schrieb eric b: Just en passant, I'd suggest to rename the preferences folder, e.g. : ~/Library/Application Support/ApacheOpenOffice/ on Mac OS X to avoid confusion with the previous 3.3.x What do you think ? Of course a good thing. But I think it's a logical step as OOo is now done in any form of appearance in the product. IMHO this applies also for the strings in the basename for the install and user directory. Sure, we'll have to : - modify the application name ( instsetoo_native, sysui, desktop, setup_native) - change the logos (ooo_custom_images, setup_native, sysui) On all OS's that is, but this is not a problem imho. In fact, rename the preferences folder is the direct and most simple way to install Apache OpenOffice.org beside OpenOffice.org without break anything. Regards, Eric Bachard -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hello, Am 03.12.2011 11:39, schrieb eric b: Hi, Le 3 déc. 11 à 11:09, Marcus (OOo) a écrit : Am 12/02/2011 09:25 PM, schrieb eric b: Just en passant, I'd suggest to rename the preferences folder, e.g. : ~/Library/Application Support/ApacheOpenOffice/ on Mac OS X to avoid confusion with the previous 3.3.x What do you think ? any thoughts of migrating the user settings from OOo to AOO? Regards, Olaf Of course a good thing. But I think it's a logical step as OOo is now done in any form of appearance in the product. IMHO this applies also for the strings in the basename for the install and user directory. Sure, we'll have to : - modify the application name ( instsetoo_native, sysui, desktop, setup_native) - change the logos (ooo_custom_images, setup_native, sysui) On all OS's that is, but this is not a problem imho. In fact, rename the preferences folder is the direct and most simple way to install Apache OpenOffice.org beside OpenOffice.org without break anything. Regards, Eric Bachard
Re: [Code] strategy for child works spaces
Salut eric, On 23.11.2011 17:21, eric b wrote: Hello Armin, Le 23 nov. 11 à 16:48, Armin Le Grand a écrit : [..] Great ! Now, I'll have to retrieve the command line to extract the diff :-) If I'm not too wrong, could be something like: svn diff http//... main http:// your branch/main my_full_diff.diff in place. I'm just co'ing these and will then add my changes. @eric: It will soon be possible to take a look at svg replacement :-) Sure I will. thank you very much ! Feel free to fetch and build the first version of Svg replacement on https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement. Win and mac version built, linux not yet. Looking forward to Your findings, esp. bugs of course :-) Regards, Eric Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi, Answering to myself, build completed (some hacks mandatory, mostly berkeleydb and rhino broken) on Mac OS X 10.4, for en-US, de and fr locales. They should work on all Mac OS X Intel, from 10.4 to 10.7 Is there a place I could upload those builds for testing purpose ? On the testing side now ... first test : opening the first .svg I found on the web - no problem. Second test : .svg export does nothing (reopen the exported .svg gives a white page) Just en passant, I'd suggest to rename the preferences folder, e.g. : ~/Library/Application Support/ApacheOpenOffice/ on Mac OS X to avoid confusion with the previous 3.3.x What do you think ? Thanks in advance, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hello guys; Maho and I have been battling with an issue related to the linking order on the vcl module for the FreeBSD port. A quick look on the gnumake4 CWS, in particular http://hg.services.openoffice.org/hg/cws/gnumake4/file/b3086537b169/vcl/Library_vcl.mk makes me think it is fixed there. I think the best way to get it tested is to commit it but if this is not acceptable for any reason please at least make the patch available. Pedro. --- On Sat, 11/26/11, eric b eric.bach...@free.fr wrote: ... It is highly probable that it won't introduce any regression on the core functionality, Any important change needs some tests. This is one important change. IMO everybody will benefit from its integration in the trunk, so I'd vote for integrating this into trunk. [.. cut ...] What do you guys think? Used with zilllion of OpenOffice.org builds, on every OS, I have seen a lot of issues, and replace dmake IMHO worth to create a branch and verify nothing is wrong. Anyway, I'll follow what people say. Regards, Eric --qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi; It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. cheers, Pedro. --- On Thu, 11/24/11, Ariel Constenla-Haile arie...@apache.org wrote: ... Hi Michael, * On Fri, Nov 25, 2011 at 12:04:24AM +0100, Michael Stahl wrote: hi Ariel, On 23.11.2011 17:16, Ariel Constenla-Haile wrote: On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. In the meantime I got carried away and ended today in the morning, fun applying patches instead of reading endless discussions on the ml. I didn't find info about the milestone the cws was based, so I searched the log and started from # HG changeset patch # # User mba # # Date 1298363591 -3600 # # Node ID fe9439d524ff71df9122398fefd218ec7b6559db # # Parent 1ed7b2431f1039853910a27430061b3bd3a75d4b # CWS gnumake4: add support for zip and jar files this is the first of a set a changes by Mathias to convert wizards to gbuild, the log didn't show previous related stuff, so I took this as the starting point. The patches ended with # HG changeset patch # # User Michael Stahl m...@openoffice.org # # Date 1303985562 0 # # Node ID b3086537b169c6c46d2347df9b319d837f861c41 # # Parent 87a6f58da4b509f7130196156be86a4941fa229c # gnumake4: writerfilter: temporarily disable complex test I added the set of patches from writerfilter10 by Henning Brinkmann, but I guess I should revert that and only apply the ones related to convert writerfilter to gbuild. Now I did a diff between gnumake4 and the resulting code, to see if I missed something (I'm only comparing the affected directories). Compiling some modules shows some issues with the migration, so I'm working on this now. uhm, i kind of already have re-based that onto OOO340m1 some time in August, and am sitting on 150 or so patches that are basically just waiting for the 3.4 branch off so they can go into trunk. well i guess they need to be re-based again because of the changes to the build system in AOOo. if you are impatient :) then i can mail them to you or something, I followed yours and Eike's advice in this thread http://s.apache.org/6lm so I guess your patches won't be too different from the ones I applied. Anyway feel free to send them. no need to re-invent the wheel here oh I'm a pragmatic guy, and I do this in my spare time, so if I had known you already had the patches (and were willing to contribute them), I wouldn't have started working on this :) (but somehow i get the feeling that AOOo is all about re-inventing wheels...) well... most things you read hear are just words. I guess some people have too much time to write, and, on the other hand, some things are written having no idea at all of what it takes to write some code for OOo, compile it, debug it, see you didn't break anything, etc. etc. So it might look possible to kill seamonkey and write brand new AL2 stuff. Regards -- Ariel Constenla-Haile La Plata, Argentina
gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi Pedro, * On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote: Hi; It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). I'm not sure if the gnumake4 integration should be moved to a feature branch. It is highly probable that it won't introduce any regression on the core functionality, as most changes are made to Makefiles, and in the cases where the source code was, it only had to do with fixing the exported symbols, among other little changes; there are no core new features, it is only the build system. IMO everybody will benefit from its integration in the trunk, so I'd vote for integrating this into trunk. Of course, it is highly probable that our builds will brake, but it can be fixed soon, while people is building. On the other hand, having this in a feature branch will mean more work with merging the trunk changesets (I already had to do this with the cppunit removal, which by the way would have been more simple and clean with the gnumake4 changes). What do you guys think? Regards -- Ariel Constenla-Haile La Plata, Argentina pgpl2RLWibkJS.pgp Description: PGP signature
RE: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
-Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Saturday, 26 November 2011 8:34 AM To: ooo-dev@incubator.apache.org Subject: gnumake4 integration (was: Re: [Code] strategy for child works spaces) Hi Pedro, * On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote: Hi; It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). Sorry to hijack, where are the requirements and build instructions for building on XP (and Win 7 too if possible.) Thanks Gav... I'm not sure if the gnumake4 integration should be moved to a feature branch. It is highly probable that it won't introduce any regression on the core functionality, as most changes are made to Makefiles, and in the cases where the source code was, it only had to do with fixing the exported symbols, among other little changes; there are no core new features, it is only the build system. IMO everybody will benefit from its integration in the trunk, so I'd vote for integrating this into trunk. Of course, it is highly probable that our builds will brake, but it can be fixed soon, while people is building. On the other hand, having this in a feature branch will mean more work with merging the trunk changesets (I already had to do this with the cppunit removal, which by the way would have been more simple and clean with the gnumake4 changes). What do you guys think? Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
+1 from me I am pretty sure this wont interfere with the IP Clearance that is left and even there, getting us less dependent on Dmake is good. Pedro. --- On Fri, 11/25/11, Ariel Constenla-Haile arie...@apache.org wrote: ... Hi Pedro, * On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote: Hi; It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). I'm not sure if the gnumake4 integration should be moved to a feature branch. It is highly probable that it won't introduce any regression on the core functionality, as most changes are made to Makefiles, and in the cases where the source code was, it only had to do with fixing the exported symbols, among other little changes; there are no core new features, it is only the build system. IMO everybody will benefit from its integration in the trunk, so I'd vote for integrating this into trunk. Of course, it is highly probable that our builds will brake, but it can be fixed soon, while people is building. On the other hand, having this in a feature branch will mean more work with merging the trunk changesets (I already had to do this with the cppunit removal, which by the way would have been more simple and clean with the gnumake4 changes). What do you guys think? Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hello Gavin, On Sat, Nov 26, 2011 at 08:39:20AM +1000, Gavin McDonald wrote: I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). Sorry to hijack, where are the requirements and build instructions for building on XP (and Win 7 too if possible.) you can find information on the Building Guide http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows It needs some updates about: * ATL, Mathias said it is possible to get ATL if you install the Driver SDK * a newer DirectX SDK works, IIRC Andre added support for the latest one Instructions about Getting the Source are outdated http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Getting_the_source Apache OpenOffice works with SVN (though I guess most of us use git-svn). Regards -- Ariel Constenla-Haile La Plata, Argentina pgp5UkbnuA3p6.pgp Description: PGP signature
Re: gnumake4 integration (was: Re: [Code] strategy for child works spaces)
Hi Ariel, Le 25 nov. 11 à 23:34, Ariel Constenla-Haile a écrit : Hi Pedro, * On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote: Hi; It looks like the IP Clearance stuff is under control so I would like to move completely to a development branch if you guys create it. I also suspect the FreeBSD port will need adjustments for the new gnumake stuff. I have finished building on Fedora 16 64 bits, and fixing some issues. I started building on WinXP (a VM, so it takes 5 hrs). I'm not sure if the gnumake4 integration should be moved to a feature branch. Please use a feature branch : it is always possible to forgot some parts, making the final set apparently working but unusable and the end, and the problem difficult to track and being solved. It is highly probable that it won't introduce any regression on the core functionality, Any important change needs some tests. This is one important change. IMO everybody will benefit from its integration in the trunk, so I'd vote for integrating this into trunk. [.. cut ...] What do you guys think? Used with zilllion of OpenOffice.org builds, on every OS, I have seen a lot of issues, and replace dmake IMHO worth to create a branch and verify nothing is wrong. Anyway, I'll follow what people say. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Pedro, On 23.11.2011 17:08, Pedro Giffuni wrote: Hi; That's very cool. Thanks Armand! I've checked out the status of AGG and while the new version is GPL'd, it was abandoned and the community has done some enhancements on the BSD licensed version that I could bring in. I thought AGG would've been useful for your SVG stuff but it looks like I was wrong. Would you guys prefer that I remove it altogether or should I wait until after 3.4 to kill it. From my POV I would remove it. If we need it again, it's in the repository history. The smaller the trunk is the better! FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: ause131 ause130 writerfilter10 gnumake4 sd2gbuild cheers, Pedro. --- On Wed, 11/23/11, Armin Le Grandarmin.le.gr...@me.com wrote: [..] -- ALG
Re: [Code] strategy for child works spaces
Salut eric, On 23.11.2011 17:21, eric b wrote: Hello Armin, Le 23 nov. 11 à 16:48, Armin Le Grand a écrit : Hi *, I have now started to add my cwses to branches, at least the long lasting ones. I have not created a cws directory since there already was a /branches directory, so no need to work besides conventions others might be used to. I have added a directory to /branches and then copied the trunc to the cwses I wanted to create, thus there is now /branches/alg/svgreplacement /branches/alg/aw080 Great ! Now, I'll have to retrieve the command line to extract the diff :-) If I'm not too wrong, could be something like: svn diff http//... main http:// your branch/main my_full_diff.diff in place. I'm just co'ing these and will then add my changes. @eric: It will soon be possible to take a look at svg replacement :-) Sure I will. thank you very much ! To avoid double work, please wait for my okay, I have not yet checked in something on that branches. I'll first have to take my stuff to diffs and apply them, this will need a while (with test build)... Regards, Eric
Re: [Code] strategy for child works spaces
Hi Eric, On 24.11.2011 11:01, Armin Le Grand wrote: Salut eric, [..] To avoid double work, please wait for my okay, I have not yet checked in something on that branches. I'll first have to take my stuff to diffs and apply them, this will need a while (with test build)... OOps, also todo: Exchange old headers for newly created files to apache license, nearly forgot that! I prefer to put all the money into the chocolate, thus it will not be my main thread to move the stuff over, but it's going forward... Sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
hi Ariel, On 23.11.2011 17:16, Ariel Constenla-Haile wrote: On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. uhm, i kind of already have re-based that onto OOO340m1 some time in August, and am sitting on 150 or so patches that are basically just waiting for the 3.4 branch off so they can go into trunk. well i guess they need to be re-based again because of the changes to the build system in AOOo. if you are impatient :) then i can mail them to you or something, no need to re-invent the wheel here (but somehow i get the feeling that AOOo is all about re-inventing wheels...) regards, michael
Re: [Code] strategy for child works spaces
Hi Michael, * On Fri, Nov 25, 2011 at 12:04:24AM +0100, Michael Stahl wrote: hi Ariel, On 23.11.2011 17:16, Ariel Constenla-Haile wrote: On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. In the meantime I got carried away and ended today in the morning, fun applying patches instead of reading endless discussions on the ml. I didn't find info about the milestone the cws was based, so I searched the log and started from # HG changeset patch # # User mba # # Date 1298363591 -3600 # # Node ID fe9439d524ff71df9122398fefd218ec7b6559db # # Parent 1ed7b2431f1039853910a27430061b3bd3a75d4b # CWS gnumake4: add support for zip and jar files this is the first of a set a changes by Mathias to convert wizards to gbuild, the log didn't show previous related stuff, so I took this as the starting point. The patches ended with # HG changeset patch # # User Michael Stahl m...@openoffice.org # # Date 1303985562 0 # # Node ID b3086537b169c6c46d2347df9b319d837f861c41 # # Parent 87a6f58da4b509f7130196156be86a4941fa229c # gnumake4: writerfilter: temporarily disable complex test I added the set of patches from writerfilter10 by Henning Brinkmann, but I guess I should revert that and only apply the ones related to convert writerfilter to gbuild. Now I did a diff between gnumake4 and the resulting code, to see if I missed something (I'm only comparing the affected directories). Compiling some modules shows some issues with the migration, so I'm working on this now. uhm, i kind of already have re-based that onto OOO340m1 some time in August, and am sitting on 150 or so patches that are basically just waiting for the 3.4 branch off so they can go into trunk. well i guess they need to be re-based again because of the changes to the build system in AOOo. if you are impatient :) then i can mail them to you or something, I followed yours and Eike's advice in this thread http://s.apache.org/6lm so I guess your patches won't be too different from the ones I applied. Anyway feel free to send them. no need to re-invent the wheel here oh I'm a pragmatic guy, and I do this in my spare time, so if I had known you already had the patches (and were willing to contribute them), I wouldn't have started working on this :) (but somehow i get the feeling that AOOo is all about re-inventing wheels...) well... most things you read hear are just words. I guess some people have too much time to write, and, on the other hand, some things are written having no idea at all of what it takes to write some code for OOo, compile it, debug it, see you didn't break anything, etc. etc. So it might look possible to kill seamonkey and write brand new AL2 stuff. Regards -- Ariel Constenla-Haile La Plata, Argentina pgphI5GTwjZhL.pgp Description: PGP signature
Re: [Code] strategy for child works spaces
Hi *, I have now started to add my cwses to branches, at least the long lasting ones. I have not created a cws directory since there already was a /branches directory, so no need to work besides conventions others might be used to. I have added a directory to /branches and then copied the trunc to the cwses I wanted to create, thus there is now /branches/alg/svgreplacement /branches/alg/aw080 in place. I'm just co'ing these and will then add my changes. @eric: It will soon be possible to take a look at svg replacement :-) On 22.11.2011 12:12, Armin Le Grand wrote: Hi *, no further responses, thus - if no complaints - I'll start adding a branch for svg replacement soon... Sincerely, Armin On 21.11.2011 14:48, Armin Le Grand wrote: Hi eric, On 21.11.2011 14:26, eric b wrote: Hi Armin, Le 21 nov. 11 à 13:14, Armin a écrit : [..] Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? Sorry for my dumb question, but how things will work when several devs will work together on one feature ? Just work together on /cws/alg/svgreplacement after (in this example) I have created it. The branch is practically not exclusively modifyable by be, it will just be a convention to only work on branches/cwses together after being somewhat invited, IMHO. Also, what about use the cws name first, then the Apache id ? I would prefer cws first, this will give a less crowded https://svn.apache.org/repos/asf/incubator/ooo/ which is a dood thing from my POV. This makes all cwses appear in cws, thus you will not have to scan all names in https://svn.apache.org/repos/asf/incubator/ooo/ for what you are looking. In former developent we had somewhat of 150-200 cwses open, thus i would definitely prefer them to be in an own path, and even add the developers name to it. Thus, in https://svn.apache.org/repos/asf/incubator/ooo/ where you will naturally look for orientation you will have something like cws dev experiment ... but not a list of 150-200 branches in the works. Could give : /cws/svgreplacement/alg /cws/svgreplacement/another_contributor This would mean that another_contributor is not joining to work on svgreplacement, but has branched it to do his own things with it. Possible, but hopefully never needed :-) Please be gentle if I was plain wrong :-) Regards, Eric sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi; That's very cool. Thanks Armand! I've checked out the status of AGG and while the new version is GPL'd, it was abandoned and the community has done some enhancements on the BSD licensed version that I could bring in. I thought AGG would've been useful for your SVG stuff but it looks like I was wrong. Would you guys prefer that I remove it altogether or should I wait until after 3.4 to kill it. FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: ause131 ause130 writerfilter10 gnumake4 sd2gbuild cheers, Pedro. --- On Wed, 11/23/11, Armin Le Grand armin.le.gr...@me.com wrote: From: Armin Le Grand armin.le.gr...@me.com Subject: Re: [Code] strategy for child works spaces To: ooo-dev@incubator.apache.org Date: Wednesday, November 23, 2011, 10:48 AM Hi *, I have now started to add my cwses to branches, at least the long lasting ones. I have not created a cws directory since there already was a /branches directory, so no need to work besides conventions others might be used to. I have added a directory to /branches and then copied the trunc to the cwses I wanted to create, thus there is now /branches/alg/svgreplacement /branches/alg/aw080 in place. I'm just co'ing these and will then add my changes. @eric: It will soon be possible to take a look at svg replacement :-) On 22.11.2011 12:12, Armin Le Grand wrote: Hi *, no further responses, thus - if no complaints - I'll start adding a branch for svg replacement soon... Sincerely, Armin On 21.11.2011 14:48, Armin Le Grand wrote: Hi eric, On 21.11.2011 14:26, eric b wrote: Hi Armin, Le 21 nov. 11 à 13:14, Armin a écrit : [..] Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? Sorry for my dumb question, but how things will work when several devs will work together on one feature ? Just work together on /cws/alg/svgreplacement after (in this example) I have created it. The branch is practically not exclusively modifyable by be, it will just be a convention to only work on branches/cwses together after being somewhat invited, IMHO. Also, what about use the cws name first, then the Apache id ? I would prefer cws first, this will give a less crowded https://svn.apache.org/repos/asf/incubator/ooo/ which is a dood thing from my POV. This makes all cwses appear in cws, thus you will not have to scan all names in https://svn.apache.org/repos/asf/incubator/ooo/ for what you are looking. In former developent we had somewhat of 150-200 cwses open, thus i would definitely prefer them to be in an own path, and even add the developers name to it. Thus, in https://svn.apache.org/repos/asf/incubator/ooo/ where you will naturally look for orientation you will have something like cws dev experiment ... but not a list of 150-200 branches in the works. Could give : /cws/svgreplacement/alg /cws/svgreplacement/another_contributor This would mean that another_contributor is not joining to work on svgreplacement, but has branched it to do his own things with it. Possible, but hopefully never needed :-) Please be gentle if I was plain wrong :-) Regards, Eric sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpsMvEpO9rSz.pgp Description: PGP signature
Re: [Code] strategy for child works spaces
Hi Ariel, Le 23 nov. 11 à 17:16, Ariel Constenla-Haile a écrit : On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. To be sure : is the plan to use gmake for the whole build ? Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hello Armin, Le 23 nov. 11 à 16:48, Armin Le Grand a écrit : Hi *, I have now started to add my cwses to branches, at least the long lasting ones. I have not created a cws directory since there already was a /branches directory, so no need to work besides conventions others might be used to. I have added a directory to /branches and then copied the trunc to the cwses I wanted to create, thus there is now /branches/alg/svgreplacement /branches/alg/aw080 Great ! Now, I'll have to retrieve the command line to extract the diff :-) If I'm not too wrong, could be something like: svn diff http//... mainhttp:// your branch/main my_full_diff.diff in place. I'm just co'ing these and will then add my changes. @eric: It will soon be possible to take a look at svg replacement :-) Sure I will. thank you very much ! Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Eric, *, --- On Wed, 11/23/11, eric b eric.bach...@free.fr wrote: ... To be sure : is the plan to use gmake for the whole build ? That's the plan but my understanding is that gnumake4 doesn't yet achieve that completely. cheers, Pedro.
Re: [Code] strategy for child works spaces
HI eric, * On Wed, Nov 23, 2011 at 05:16:35PM +0100, eric b wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. To be sure : is the plan to use gmake for the whole build ? the original plan is to replace the old build.pl/dmake build system with a new GNU make base one (there was a blog post on GullFOSS, now dead, explaining that). So far, with the commits I've applied, gnumake4 converts the following modules to gbuild: basebmp basegfx canvas cppcanvas idl linguistic sax starmath ucbhelper unotools wizards xmlreader xmlscript not yet applied, but seen in that cws too: dbaccess oox reportdesign writerfilter Regards -- Ariel Constenla-Haile La Plata, Argentina pgpmg36Qf43ay.pgp Description: PGP signature
Re: [Code] strategy for child works spaces
Am 23.11.2011 19:40, schrieb Ariel Constenla-Haile: HI eric, * On Wed, Nov 23, 2011 at 05:16:35PM +0100, eric b wrote: FWIW, Michael Stahl had these CWSs in the pipeline, I hope he or someone else finds the time to merge them into some branch: gnumake4 I started working in this one. I took the apply-per-commmit approach (I did one big diff but was very error prone). They are ca. 180 commits, may be I'll finish by next Monday dedicating 2 hrs per day. To be sure : is the plan to use gmake for the whole build ? the original plan is to replace the old build.pl/dmake build system with a new GNU make base one (there was a blog post on GullFOSS, now dead, explaining that). So far, with the commits I've applied, gnumake4 converts the following modules to gbuild: basebmp basegfx canvas cppcanvas idl linguistic sax starmath ucbhelper unotools wizards xmlreader xmlscript not yet applied, but seen in that cws too: dbaccess oox reportdesign writerfilter IIRC a cws that brings writerfilter to gbuild was already merged into gnumake4. Regards, Mathias
Re: [Code] strategy for child works spaces
Hi *, no further responses, thus - if no complaints - I'll start adding a branch for svg replacement soon... Sincerely, Armin On 21.11.2011 14:48, Armin Le Grand wrote: Hi eric, On 21.11.2011 14:26, eric b wrote: Hi Armin, Le 21 nov. 11 à 13:14, Armin a écrit : [..] Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? Sorry for my dumb question, but how things will work when several devs will work together on one feature ? Just work together on /cws/alg/svgreplacement after (in this example) I have created it. The branch is practically not exclusively modifyable by be, it will just be a convention to only work on branches/cwses together after being somewhat invited, IMHO. Also, what about use the cws name first, then the Apache id ? I would prefer cws first, this will give a less crowded https://svn.apache.org/repos/asf/incubator/ooo/ which is a dood thing from my POV. This makes all cwses appear in cws, thus you will not have to scan all names in https://svn.apache.org/repos/asf/incubator/ooo/ for what you are looking. In former developent we had somewhat of 150-200 cwses open, thus i would definitely prefer them to be in an own path, and even add the developers name to it. Thus, in https://svn.apache.org/repos/asf/incubator/ooo/ where you will naturally look for orientation you will have something like cws dev experiment ... but not a list of 150-200 branches in the works. Could give : /cws/svgreplacement/alg /cws/svgreplacement/another_contributor This would mean that another_contributor is not joining to work on svgreplacement, but has branched it to do his own things with it. Possible, but hopefully never needed :-) Please be gentle if I was plain wrong :-) Regards, Eric sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
Hi *, On 19.11.2011 21:40, Rob Weir wrote: On Sat, Nov 19, 2011 at 3:29 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? You know what, I bet we're not the First Ones in the History of the Universe to use branches in SVN. So rather than fill this list with needless speculation on what is and what isn't supported, and what works best, I'd recommend we all just take the time to do some homework and read what the experts have written: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html I took the time to study this to some degree, and it looks valuable (and manageable). Since we have such a case currently with Svg replacement I offer to test this. I have a pretty advanced version of the Svg replacement now, but still locally (and some backups on an external drive), but nothing I would call safe compared to a checked-in version on a well managed server. Also already some people opted to take a look and test it, also a situation to use a Svn branch. We need to talk about the syntax, though. The most used one seems to be to use something like https://svn.apache.org/repos/asf/incubator/ooo/branches/svnreplacement or (remembering CWSes): https://svn.apache.org/repos/asf/incubator/ooo/cws/svnreplacement What would be preferred and should I just start doing it...? Sincerely, Armin http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html -Rob -- ALG
Re: [Code] strategy for child works spaces
On Mon, Nov 21, 2011 at 5:22 AM, Armin Le Grand armin.le.gr...@me.com wrote: Hi *, On 19.11.2011 21:40, Rob Weir wrote: On Sat, Nov 19, 2011 at 3:29 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? You know what, I bet we're not the First Ones in the History of the Universe to use branches in SVN. So rather than fill this list with needless speculation on what is and what isn't supported, and what works best, I'd recommend we all just take the time to do some homework and read what the experts have written: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html I took the time to study this to some degree, and it looks valuable (and manageable). Since we have such a case currently with Svg replacement I offer to test this. I have a pretty advanced version of the Svg replacement now, but still locally (and some backups on an external drive), but nothing I would call safe compared to a checked-in version on a well managed server. Also already some people opted to take a look and test it, also a situation to use a Svn branch. We need to talk about the syntax, though. The most used one seems to be to use something like https://svn.apache.org/repos/asf/incubator/ooo/branches/svnreplacement or (remembering CWSes): https://svn.apache.org/repos/asf/incubator/ooo/cws/svnreplacement As you have probably read, these are just cheap copies / copy on write references in SVN, so the directory name does not really matter. There might be some advantage to prefacing the name with your Apache ID, e.g., alg-svnreplacement so it is easy to find all of your own feature branches. What would be preferred and should I just start doing it...? We could do it entirely in /branches if we adopt a naming scheme, like DEV* for release stabilization branches and Apache-ID-* for individual feature branches. Or separate these with different directories, per your example. I don't think the tools care one way or another. Would you ever want/need to check out all CWS's but not release branches? Or want to grep all CWS's but not the DEV branches, or do any other operation that would impact only the CWS's together? If so, having them in different directories would help a little. -Rob Sincerely, Armin http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html -Rob -- ALG
Re: [Code] strategy for child works spaces
Rob Weir robw...@apache.org wrote: On Mon, Nov 21, 2011 at 5:22 AM, Armin Le Grand armin.le.gr...@me.com wrote: Hi *, On 19.11.2011 21:40, Rob Weir wrote: On Sat, Nov 19, 2011 at 3:29 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? You know what, I bet we're not the First Ones in the History of the Universe to use branches in SVN. So rather than fill this list with needless speculation on what is and what isn't supported, and what works best, I'd recommend we all just take the time to do some homework and read what the experts have written: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html I took the time to study this to some degree, and it looks valuable (and manageable). Since we have such a case currently with Svg replacement I offer to test this. I have a pretty advanced version of the Svg replacement now, but still locally (and some backups on an external drive), but nothing I would call safe compared to a checked-in version on a well managed server. Also already some people opted to take a look and test it, also a situation to use a Svn branch. We need to talk about the syntax, though. The most used one seems to be to use something like https://svn.apache.org/repos/asf/incubator/ooo/branches/svnreplacement or (remembering CWSes): https://svn.apache.org/repos/asf/incubator/ooo/cws/svnreplacement As you have probably read, these are just cheap copies / copy on write references in SVN, so the directory name does not really matter. Yes, I read that. just as expected :-) There might be some advantage to prefacing the name with your Apache ID, e.g., alg-svnreplacement so it is easy to find all of your own feature branches. What would be preferred and should I just start doing it...? We could do it entirely in /branches if we adopt a naming scheme, like DEV* for release stabilization branches and Apache-ID-* for individual feature branches. Or separate these with different directories, per your example. I don't think the tools care one way or another. Would you ever want/need to check out all CWS's but not release branches? Or want to grep all CWS's but not the DEV branches, or do any other operation that would impact only the CWS's together? If so, having them in different directories would help a little. Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? -Rob Sincerely, Armin http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html -Rob -- ALG -- ALG
Re: [Code] strategy for child works spaces
Hi Armin, Le 21 nov. 11 à 13:14, Armin a écrit : Rob Weir robw...@apache.org wrote: As you have probably read, these are just cheap copies / copy on write references in SVN, so the directory name does not really matter. Yes, I read that. just as expected :-) There might be some advantage to prefacing the name with your Apache ID, e.g., alg-svnreplacement so it is easy to find all of your own feature branches. What would be preferred and should I just start doing it...? We could do it entirely in /branches if we adopt a naming scheme, like DEV* for release stabilization branches and Apache-ID-* for individual feature branches. Or separate these with different directories, per your example. I don't think the tools care one way or another. Would you ever want/need to check out all CWS's but not release branches? Or want to grep all CWS's but not the DEV branches, or do any other operation that would impact only the CWS's together? If so, having them in different directories would help a little. Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? Sorry for my dumb question, but how things will work when several devs will work together on one feature ? Also, what about use the cws name first, then the Apache id ? Could give : /cws/svgreplacement/alg /cws/svgreplacement/another_contributor Please be gentle if I was plain wrong :-) Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi eric, On 21.11.2011 14:26, eric b wrote: Hi Armin, Le 21 nov. 11 à 13:14, Armin a écrit : [..] Interesting point. It may be useful to grep own cwses, or releases. Thus something like /cws/alg/svgreplacement /cws/alg/... /cws/someonelse/... /dev/aoo340 /dev/aoo350 ... would be nice. Comments, anyone? Sorry for my dumb question, but how things will work when several devs will work together on one feature ? Just work together on /cws/alg/svgreplacement after (in this example) I have created it. The branch is practically not exclusively modifyable by be, it will just be a convention to only work on branches/cwses together after being somewhat invited, IMHO. Also, what about use the cws name first, then the Apache id ? I would prefer cws first, this will give a less crowded https://svn.apache.org/repos/asf/incubator/ooo/ which is a dood thing from my POV. This makes all cwses appear in cws, thus you will not have to scan all names in https://svn.apache.org/repos/asf/incubator/ooo/ for what you are looking. In former developent we had somewhat of 150-200 cwses open, thus i would definitely prefer them to be in an own path, and even add the developers name to it. Thus, in https://svn.apache.org/repos/asf/incubator/ooo/ where you will naturally look for orientation you will have something like cws dev experiment ... but not a list of 150-200 branches in the works. Could give : /cws/svgreplacement/alg /cws/svgreplacement/another_contributor This would mean that another_contributor is not joining to work on svgreplacement, but has branched it to do his own things with it. Possible, but hopefully never needed :-) Please be gentle if I was plain wrong :-) Regards, Eric sincerely, Armin -- ALG
Re: [Code] strategy for child works spaces
On 20.11.2011 12:22, Christian Lohmaier wrote: Hi Eric, *, On Sun, Nov 20, 2011 at 10:12 AM, eric beric.bach...@free.fr wrote: Le 19 nov. 11 à 22:55, Mathias Bauer a écrit : Am 19.11.2011 15:22, schrieb Pedro Giffuni: I still prefer the conversion of a cws in single diffs, each one representing a single commit. Me too. That's the most efficient way to integrate a cws. No, it is not. A cws can be long lived, could have underwent multiple rebases with the current tree, so there are lots of commits that refer to a old version of the code and thus won't apply anymore. Unless you want to do lots of detecitve work and redo all the merging work that the author of the cws did do already over the course of time, trying to apply a cws by its individual commits is a waste of time, not to mention that it is The version to apply a cws to a different version-control system is to create a diff agains the current milestone the cws is based on and try to apply that one. (feel free to create a diff for each module). This will give way less conflicts and is much faster. You loose history, but that was your decision when converting the repo to begin with. As I tried both methods on some cws already, I don't recommend the one cws diff method, except in one single case (see below). You will get merge conflicts in both ways, but by turning a cws into single diffs you will get smaller merges, and especially you will get many merges that someone already did. Looking on the merge commits in Mercurial will help you with the conflict resolution. Applying huge diffs in code you don't know perfectly is hard. Applying diffs that each represent a single change with better defined meaning and intent should be easier and less error-prone. It might take a little bit longer, but the result will be better and the developers carrying out the integration can learn something about the code. Of course, if a cws isn't well organized with commits of manageable size and at least somewhat helpful comments, working with single commit diffs would suffer from its disadvantages without the advantages - so applying a single diff and trying hard might be more efficient. But you will lose the cws history then and I still think we should preserve it when possible (it wasn't for the stuff already integrated, unfortunately, but that's no reason to lose everything else too). Regards, Mathias
Re: [Code] strategy for child works spaces
Hi Mathias, Le 19 nov. 11 à 22:55, Mathias Bauer a écrit : Am 19.11.2011 15:22, schrieb Pedro Giffuni: I think we could use a SVN branch as a buffer to integrate CWSs one by one; that way we don't interrupt current work and get to try the CWSs before the tree changes too much to make merging difficult. Creating branches is very easy and any committer can do it. Is there a way to get CWSs as diffs? You mean the existing ones from hg? We discussed that some weeks ago. Sorry, I missed the discussion :/ I still prefer the conversion of a cws in single diffs, each one representing a single commit. Me too. That's the most efficient way to integrate a cws. It seems to be doable for most cws. For the ones we integrated, the diffs have been applied to the trunk, there's nothing that prevents that they could be applied to branches. Are full diff existing somewhere ? Using Midnight Commander, that's very easy for me to create single diffs (or adapt them to the current code). If not how to extract them (using hg I mean) ? Would be great if somebody could propose the generic command line allowing to extract one. If already done, is there a location where such full diffs could be downloaded. If not existing, we could create a subdir in the trunk, containing the full diffs, and checkout them. Once turned into single diffs, and after commiting them, we could remove the full diffs, as done. Apologies if ever such process already started. In such case could you remind me where we are today, or simply point me the right link. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Eric, *, On Sun, Nov 20, 2011 at 10:12 AM, eric b eric.bach...@free.fr wrote: Le 19 nov. 11 à 22:55, Mathias Bauer a écrit : Am 19.11.2011 15:22, schrieb Pedro Giffuni: I still prefer the conversion of a cws in single diffs, each one representing a single commit. Me too. That's the most efficient way to integrate a cws. No, it is not. A cws can be long lived, could have underwent multiple rebases with the current tree, so there are lots of commits that refer to a old version of the code and thus won't apply anymore. Unless you want to do lots of detecitve work and redo all the merging work that the author of the cws did do already over the course of time, trying to apply a cws by its individual commits is a waste of time, not to mention that it is The version to apply a cws to a different version-control system is to create a diff agains the current milestone the cws is based on and try to apply that one. (feel free to create a diff for each module). This will give way less conflicts and is much faster. You loose history, but that was your decision when converting the repo to begin with. ciao Christian
Re: [Code] strategy for child works spaces
Hi Christian, Le 20 nov. 11 à 12:22, Christian Lohmaier a écrit : Hi Eric, *, On Sun, Nov 20, 2011 at 10:12 AM, eric b eric.bach...@free.fr wrote: Le 19 nov. 11 à 22:55, Mathias Bauer a écrit : Am 19.11.2011 15:22, schrieb Pedro Giffuni: I still prefer the conversion of a cws in single diffs, each one representing a single commit. Me too. That's the most efficient way to integrate a cws. No, it is not. I meant in Apache OpenOffice.org current source code we can checkout using svn. A cws can be long lived, could have underwent multiple rebases with the current tree, so there are lots of commits that refer to a old version of the code and thus won't apply anymore. My proposal was to adapt the full cws, who will very probably not apply to the sources directly. Unless you want to do lots of detecitve work and redo all the merging work that the author of the cws did do already over the course of time, trying to apply a cws by its individual commits is a waste of time, not to mention that it is Let's give an example : I download a full diff of one cws. patch -- dry-run -px the_diff The result will give some fuzz + some failed. The idea is to regenerate a new full diff, able to apply on the tree, as a set of diffs. The version to apply a cws to a different version-control system is to create a diff agains the current milestone the cws is based on and try to apply that one. (feel free to create a diff for each module). Good catch : the atomicity of the diffs is important, and yes, create one diff per modules seems more accurate. In parallel, we should maintain a log for any cws we integrated this way, of course. This will give way less conflicts and is much faster. You loose history, Yes, we loose history and I'm not satisfied with that. Just wondering whether we could keep the old full diff on the repo + add information inside the new diff ? that was your decision when converting the repo to begin with. I'm not sure to understand. You meant a common decision ? Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Am 18.11.2011 19:26, schrieb Pedro Giffuni: Hi Eric; --- On Fri, 11/18/11, eric b eric.bach...@free.fr wrote: Disclaimer: this list is not easy to read, and if the topic was already discussed. In this case, thanks in advance to provide me the right link :-) Hi, I perfectly know the importance of the IP clearance, but in parallel, we'll need to work on the code, say partialy (e.g. vcl + sd + slideshow only). In OOo we used child work spaces in that purpose, but I'm not sure we defined something similar yet with Apache OpenOffice.org. I personally don't understand well how those CWSs worked or how they are integrated. I would personally prefer if just use SVN branches exclusively from now on. I think OOo has not really used this historically, but in other projects developers have their own branches and can do work without disrupting the main tree. We have used them. At that time they where a PITA as updating them from the master or integrating them into it was very time consuming and required a lot of manual merging work. That worked much better with Mercurial, but that's not an option now, I know. We probably might want to reserve work on branches for larger code changes that require weeks or months, but integrate smaller changes directly into the master in a CI style with daily builds. Regards, Mathias
Re: [Code] strategy for child works spaces
Hi Mathias; --- On Sat, 11/19/11, Mathias Bauer mathias_ba...@gmx.net wrote: ... We have used them. At that time they where a PITA as updating them from the master or integrating them into it was very time consuming and required a lot of manual merging work. That worked much better with Mercurial, but that's not an option now, I know. I see. Integrating branches on SVN is said to be painful but to be honest there will always be many people that prefer perforce, or git or even CVS (really!). There is no such thing as a perfect tool. From my reading CWSs are actually branches, and the one thing we really lost is EIS, but I think using SVN branches directly can be very useful. I think we could use a SVN branch as a buffer to integrate CWSs one by one; that way we don't interrupt current work and get to try the CWSs before the tree changes too much to make merging difficult. Creating branches is very easy and any committer can do it. Is there a way to get CWSs as diffs? cheers, Pedro. We probably might want to reserve work on branches for larger code changes that require weeks or months, but integrate smaller changes directly into the master in a CI style with daily builds. Regards, Mathias
RE: [Code] strategy for child works spaces
This is not my area of expertise by any means. And I have a concern that this is topic is being over-simplified. This description is to test my own understanding of what it takes. - Dennis WORKING A FEATURE BRANCH The following scenario assumes that it is being performed by a committer, and if multiple committers are working on it, they are very careful in how they avoid collisions. I am going to describe this from the perspective of a single committer who is ensuring integration of a feature while working on it and before ever merging it into the main tree. For developing a feature on a branch, there is the problem of being able to test it in a build, and that means there has to be a build tree where it appears to be integrated. If the build tree has to be modified to integrate the feature, there is even more source of errors and problems when it is time to roll the feature into the trunk or main or wherever the mainline truth is. (My understanding is that the Podling SVN will not allow unresolved collisions to be checked-in, but it is also essential not to end up with a broken build.) With SVN, test builds are preferably done in working copies. If there is extensive work, this working copy is perhaps also checked into a local SVN or any other source-control system so that local reversion can be done before the next build with updated feature-branch code. The local working copy of the main tree needs to be kept current, either by updating or doing a fresh check-out. Then the feature branch is re-integrated with the local working copy for a new test build. Ideally, it is done in a way where collisions with other changes on the main tree are found and resolved at once, with the feature branch updated to eliminate its origination of any collisions. (I have not connected all the dots here. It depends on how long feature development takes and how much of the main tree has to be touched.) That way, the working copy of the feature branch is kept collision free (for now) relative to the main tree in which it was last synchronized for an integrated build. The working copy of the feature branch is checked in to the Podling SVN feature branch regularly and especially after any reconciliation with the main tree that was done to confirm build integration. When it is time to put the feature into the main tree, the feature files can be integrated a working copy of the main tree that is then checked-in. Collisions at this point will be rare and, fortunately, have to be resolved before the check-in can be completed. Obviously, the more carefully the main tree is organized, with the ability to deal with features at a module or library level with slowly-changing interfaces among modules, the easier all of this becomes: there is less of the main tree to worry about collisions in. OK, too many words and pictures would help. The simpler and more localized the feature, the better, obviously. -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Saturday, November 19, 2011 06:23 To: ooo-dev@incubator.apache.org Subject: Re: [Code] strategy for child works spaces Hi Mathias; --- On Sat, 11/19/11, Mathias Bauer mathias_ba...@gmx.net wrote: ... We have used them. At that time they where a PITA as updating them from the master or integrating them into it was very time consuming and required a lot of manual merging work. That worked much better with Mercurial, but that's not an option now, I know. I see. Integrating branches on SVN is said to be painful but to be honest there will always be many people that prefer perforce, or git or even CVS (really!). There is no such thing as a perfect tool. From my reading CWSs are actually branches, and the one thing we really lost is EIS, but I think using SVN branches directly can be very useful. I think we could use a SVN branch as a buffer to integrate CWSs one by one; that way we don't interrupt current work and get to try the CWSs before the tree changes too much to make merging difficult. Creating branches is very easy and any committer can do it. Is there a way to get CWSs as diffs? cheers, Pedro. We probably might want to reserve work on branches for larger code changes that require weeks or months, but integrate smaller changes directly into the master in a CI style with daily builds. Regards, Mathias
RE: [Code] strategy for child works spaces
--- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... This is not my area of expertise by any means. And I have a concern that this is topic is being over-simplified. This description is to test my own understanding of what it takes. I have concern that things look a lot more complex when we discuss them too much, and eventually we will not try anything at all. Of course the key would be to merge such a tree frequently with trunk, specially the minute before the branch changes are planned to be merged up: at such a point the branch should be exactly what the new trunk will become and that would guarantee that there are no conflicts. I would be interested in working in a development branch if there is a clear path to integrate some of the CWSs there. At this point I don't know how to turn those into diffs (I guess I have to do that in Hg, and I am not good at it). Otherwise I guess it's just better to wait for 3.4 to become stable and create an AOO340 prerelease branch. The developers that know well those CWSs can start merging to trunk the CWSs one by one into trunk. Either way, it works for me. cheers, Pedro.
RE: [Code] strategy for child works spaces
Pedro, Why does bringing in a CWS require creating diffs? If the CWS is installed on a client, any diffing can be done afterwards using tools that support SVN, yes? Have you checked the instructions for how non-committers can use SVN to prepare a patch from changed files in a working copy? Is there a way to exploit that for what you are thinking of? - Dennis PS: I agree that many concrete cases of working on a branch can be kept simple. But an extensive feature requires some way to be integrated for build-checking somehow. There are also preparations that can be made in the main tree by having benign stubs awaiting integration of a live feature. It all takes foresight and attention to modularization and interfaces, though. -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Saturday, November 19, 2011 10:02 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: RE: [Code] strategy for child works spaces --- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... This is not my area of expertise by any means. And I have a concern that this is topic is being over-simplified. This description is to test my own understanding of what it takes. I have concern that things look a lot more complex when we discuss them too much, and eventually we will not try anything at all. [ ... ] I would be interested in working in a development branch if there is a clear path to integrate some of the CWSs there. At this point I don't know how to turn those into diffs (I guess I have to do that in Hg, and I am not good at it). [ ... ]
Re: [Code] strategy for child works spaces
On Sat, Nov 19, 2011 at 3:29 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? You know what, I bet we're not the First Ones in the History of the Universe to use branches in SVN. So rather than fill this list with needless speculation on what is and what isn't supported, and what works best, I'd recommend we all just take the time to do some homework and read what the experts have written: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html -Rob
RE: [Code] strategy for child works spaces
--- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? If the CWS is installed on a client, any diffing can be done afterwards using tools that support SVN, yes? As I explained before I don't know how to use CWS. I look at http://hg.services.openoffice.org/hg/cws/gnumake4/ And I see a tree, and some loosely related changesets. I am interested in knowing all that changed in the branch from the time the branch was started ... therefore diff. Have you checked the instructions for how non-committers can use SVN to prepare a patch from changed files in a working copy? Is there a way to exploit that for what you are thinking of? svn diff ?? I have no problem with SVN, my problem is getting readable changes from a CWS. Branching on SVN seems pretty easy, just copying a tree to another directory and cherry-picking changesets to merge, sorry if I am oversimplifying it ;-) Pedro.
Re: [Code] strategy for child works spaces
Am 19.11.2011 15:22, schrieb Pedro Giffuni: I think we could use a SVN branch as a buffer to integrate CWSs one by one; that way we don't interrupt current work and get to try the CWSs before the tree changes too much to make merging difficult. Creating branches is very easy and any committer can do it. Is there a way to get CWSs as diffs? You mean the existing ones from hg? We discussed that some weeks ago. I still prefer the conversion of a cws in single diffs, each one representing a single commit. It seems to be doable for most cws. For the ones we integrated, the diffs have been applied to the trunk, there's nothing that prevents that they could be applied to branches. Regards, Mathias
Re: [Code] strategy for child works spaces
--- On Sat, 11/19/11, Mathias Bauer mathias_ba...@gmx.net wrote: Am 19.11.2011 15:22, schrieb Pedro Giffuni: I think we could use a SVN branch as a buffer to integrate CWSs one by one; that way we don't interrupt current work and get to try the CWSs before the tree changes too much to make merging difficult. Creating branches is very easy and any committer can do it. Is there a way to get CWSs as diffs? You mean the existing ones from hg? Yes. We discussed that some weeks ago. I still prefer the conversion of a cws in single diffs, each one representing a single commit. It seems to be doable for most cws. OK, I lost that discussion but it's OK: are there plans to merge anything else before 3.4? We still don't have a strategy for after the IP clearance: I hope after we branch for 3.4 we just don't go wild on trunk. ;). For the ones we integrated, the diffs have been applied to the trunk, there's nothing that prevents that they could be applied to branches. If it's done on trunk it's OK. It would be good to classify them and have some integration order but that's something I wouldn't know about; we'll see then. Sorry that we haven't discussed Eric's issue, which started this thread, and I got lost in the process (?). Pedro.
RE: [Code] strategy for child works spaces
For the specific situation of exploring CWS:gnumake4, I have some concrete advice: Don't try it. The changes are extensive and the effort to catch all of the incompatibilities and repair them reaches into pretty much everywhere there is a *.mk file. - Dennis ANALYSIS Here's what I did. 1. I went to the Hg CWS page: http://hg.services.openoffice.org/hg/cws/. 2. As a safeguard I downloaded the gz of CWS:gnumake4. It is a 251MB file identified as gnumake4-b3086537b169.tar.gz, although I didn't have to fool with it. 3. I then created a file folder named cws-gnumake4. I used TortoiseHg (2.1.2-x64) to clone the the CWS into that folder. This is the hg command that was used: hg clone --verbose -- http://hg.services.openoffice.org/hg/cws/gnumake4/ . (correct any linewrap. Also at the end is a . for the current directory, which was the new directory cws-gnumake4) 4. The clone is for a complete OOo tree of course, and it takes a while. 5. When the clone was completed, I was able to right-click on the top folder and launch the TortoiseSVN Workbench tool. This is to see the full revision graph of the cloned repository. I think hgk and hgview are possible alternatives on Linux/Unix systems. 6. The bad news: Looking down the default path (the root of the graph to my working directory copy), each node that represents a commit can be clicked to see what happened. It will show the commit message, and a list of all of the files involved (deleted, added, and modified). Click on any modified file and a patch is shown of what the change was. There are 27 linear changes before things get pretty confusing. But 113 (not-necessarily different) files are involved just among those changes. 28 back, a merge of writerfilter10 happens. Before that there are merges of 00034fixes, etc. Also, the gnumake4 path keeps going. It looks like it goes back at least 8 months. There's some gnumake3 merging too. All of the changes I inspected were to *.mk files. I got cross-eyed following paths backward in the graph and gave up without finding where gnumake4 started. -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Saturday, November 19, 2011 13:40 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: RE: [Code] strategy for child works spaces --- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? If the CWS is installed on a client, any diffing can be done afterwards using tools that support SVN, yes? As I explained before I don't know how to use CWS. I look at http://hg.services.openoffice.org/hg/cws/gnumake4/ And I see a tree, and some loosely related changesets. I am interested in knowing all that changed in the branch from the time the branch was started ... therefore diff. Have you checked the instructions for how non-committers can use SVN to prepare a patch from changed files in a working copy? Is there a way to exploit that for what you are thinking of? svn diff ?? I have no problem with SVN, my problem is getting readable changes from a CWS. Branching on SVN seems pretty easy, just copying a tree to another directory and cherry-picking changesets to merge, sorry if I am oversimplifying it ;-) Pedro.
RE: [Code] strategy for child works spaces
That was a very specific, to the point analysis! Thank you very much! Pedro. --- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: For the specific situation of exploring CWS:gnumake4, I have some concrete advice: Don't try it. The changes are extensive and the effort to catch all of the incompatibilities and repair them reaches into pretty much everywhere there is a *.mk file. - Dennis ANALYSIS Here's what I did. 1. I went to the Hg CWS page: http://hg.services.openoffice.org/hg/cws/. 2. As a safeguard I downloaded the gz of CWS:gnumake4. It is a 251MB file identified as gnumake4-b3086537b169.tar.gz, although I didn't have to fool with it. 3. I then created a file folder named cws-gnumake4. I used TortoiseHg (2.1.2-x64) to clone the the CWS into that folder. This is the hg command that was used: hg clone --verbose -- http://hg.services.openoffice.org/hg/cws/gnumake4/ . (correct any linewrap. Also at the end is a . for the current directory, which was the new directory cws-gnumake4) 4. The clone is for a complete OOo tree of course, and it takes a while. 5. When the clone was completed, I was able to right-click on the top folder and launch the TortoiseSVN Workbench tool. This is to see the full revision graph of the cloned repository. I think hgk and hgview are possible alternatives on Linux/Unix systems. 6. The bad news: Looking down the default path (the root of the graph to my working directory copy), each node that represents a commit can be clicked to see what happened. It will show the commit message, and a list of all of the files involved (deleted, added, and modified). Click on any modified file and a patch is shown of what the change was. There are 27 linear changes before things get pretty confusing. But 113 (not-necessarily different) files are involved just among those changes. 28 back, a merge of writerfilter10 happens. Before that there are merges of 00034fixes, etc. Also, the gnumake4 path keeps going. It looks like it goes back at least 8 months. There's some gnumake3 merging too. All of the changes I inspected were to *.mk files. I got cross-eyed following paths backward in the graph and gave up without finding where gnumake4 started. -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Saturday, November 19, 2011 13:40 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: RE: [Code] strategy for child works spaces --- On Sat, 11/19/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Pedro, Why does bringing in a CWS require creating diffs? If the CWS is installed on a client, any diffing can be done afterwards using tools that support SVN, yes? As I explained before I don't know how to use CWS. I look at http://hg.services.openoffice.org/hg/cws/gnumake4/ And I see a tree, and some loosely related changesets. I am interested in knowing all that changed in the branch from the time the branch was started ... therefore diff. Have you checked the instructions for how non-committers can use SVN to prepare a patch from changed files in a working copy? Is there a way to exploit that for what you are thinking of? svn diff ?? I have no problem with SVN, my problem is getting readable changes from a CWS. Branching on SVN seems pretty easy, just copying a tree to another directory and cherry-picking changesets to merge, sorry if I am oversimplifying it ;-) Pedro.
Re: [Code] strategy for child works spaces
On Fri, Nov 18, 2011 at 2:56 AM, eric b eric.bach...@free.fr wrote: Disclaimer: this list is not easy to read, and if the topic was already discussed. In this case, thanks in advance to provide me the right link :-) Hi, I perfectly know the importance of the IP clearance, but in parallel, we'll need to work on the code, say partialy (e.g. vcl + sd + slideshow only). In OOo we used child work spaces in that purpose, but I'm not sure we defined something similar yet with Apache OpenOffice.org. Obviously, some parts of the IP clearance could be achieved this way too. Thus, my questions are : - what is the current strategy ? - how does it work with svn ? And if there is something existing, is the methodology available on the wiki ? To contribute to the debate, I'd suggest several mnimalistic rules : This would work. The one downside is it encourages code to sit on a developer's machine until ready to integrate. So if a harddrive crashes or a laptop is stolen or whatever, the work is entirely lost. Reviews are also harder because we need to pass around large patch files. It also makes it impossible for more than one person to work on a larger new features. Maybe for simple cases this is fine. But for larger ones we could use SVN branches? I think branches in SVN are lightweight. So we could have a naming scheme, maybe using our Apache ID. So I could have a branch called robweir_feature-name and work on that until I am ready to integrate. -Rob Methodology : 1. when starting working on a feature, an improvement or whatever, create an issue, as reference : ( https://issues.apache.org/ooo/ ) 2. inform the ooo-dev list with a subject like : [topic] working at something 3. if possible, try to describe the work in progress, on a wiki page. Sort of a draft, containing the story, and/or whatever helpfull for the developers. 4. (crazy idea) : do an IRC ClassRoom around the topic ? (questions, ideas, where / what in the code and so on, brainstorming, and keep the log) Some examples from OOo4Kids wiki (to show the principle with the wiki): - How cursors work in OpenOffice.org: http://wiki.ooo4kids.org/index.php/AddNewCursors - Password protected preferences : http://wiki.ooo4kids.org/index.php/PasswordProtectedPreferences - Math sources description : http://wiki.ooo4kids.org/index.php/ImproveMathEquationEditor/SourcesDescription As you can see, the point is not to write stupid administrative specs, but to accompany the feature implementation, and invite to ask questions (and answr them if possible). Plus share the knowledge, of course. To improve the commit system : 5. before to commit, the commiter must build and verify the change will not introduce a build breaker. Else, inform and ask for a review on the ooo-dev list, in case of doubts. Thanks in advance, Eric Bachard -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Eric; --- On Fri, 11/18/11, eric b eric.bach...@free.fr wrote: Disclaimer: this list is not easy to read, and if the topic was already discussed. In this case, thanks in advance to provide me the right link :-) Hi, I perfectly know the importance of the IP clearance, but in parallel, we'll need to work on the code, say partialy (e.g. vcl + sd + slideshow only). In OOo we used child work spaces in that purpose, but I'm not sure we defined something similar yet with Apache OpenOffice.org. I personally don't understand well how those CWSs worked or how they are integrated. I would personally prefer if just use SVN branches exclusively from now on. I think OOo has not really used this historically, but in other projects developers have their own branches and can do work without disrupting the main tree. Obviously, some parts of the IP clearance could be achieved this way too. As I see things the absolute priority is to go through the IP clearance process and before that nothing significant will be integrated. The big question is how much will we do between the IP clearance and 3.4. There are a few CWSs that could be integrated (mst had proposed a few) and I would particularly favor gnumake4 as that would be in the direction of getting rid of dmake which we will have to do sooner or later. I think for practical reasons, once the IP clearance is done we will replace a few of the features with free components and after that we will just do the release but any feature or even bug fixes will be left for after 3.4. This means 3.4 will have some very outdated components. I am particularly concerned about ICU, but I already made up to the idea it is unavoidable. Right now I think the road ahead is as follows: - Continue with IP clearance only (I estimate 2-3 weeks but it's only a guess). - Once that is over we have to discuss what features can be recovered: 1) the COIN solver. 2) Update the wpdlib support? 3) Perhaps put back MySpell in addition to Hunspell. 4) Maybe update some non-critical components (ICC?). - We branch 3.4 and only do finishing touches there. trunk can start doing aggressive CWSs merging, cleanups, new features, etc. This surely requires more discussion and thinking, but that's about all the planning I have in mind ATM. Pedro. Thus, my questions are : - what is the current strategy ? - how does it work with svn ? And if there is something existing, is the methodology available on the wiki ? To contribute to the debate, I'd suggest several mnimalistic rules : Methodology : 1. when starting working on a feature, an improvement or whatever, create an issue, as reference : ( https://issues.apache.org/ooo/ ) 2. inform the ooo-dev list with a subject like : [topic] working at something 3. if possible, try to describe the work in progress, on a wiki page. Sort of a draft, containing the story, and/or whatever helpfull for the developers. 4. (crazy idea) : do an IRC ClassRoom around the topic ? (questions, ideas, where / what in the code and so on, brainstorming, and keep the log) Some examples from OOo4Kids wiki (to show the principle with the wiki): - How cursors work in OpenOffice.org: http://wiki.ooo4kids.org/index.php/AddNewCursors - Password protected preferences : http://wiki.ooo4kids.org/index.php/PasswordProtectedPreferences - Math sources description : http://wiki.ooo4kids.org/index.php/ImproveMathEquationEditor/SourcesDescription As you can see, the point is not to write stupid administrative specs, but to accompany the feature implementation, and invite to ask questions (and answr them if possible). Plus share the knowledge, of course. To improve the commit system : 5. before to commit, the commiter must build and verify the change will not introduce a build breaker. Else, inform and ask for a review on the ooo-dev list, in case of doubts. Thanks in advance, Eric Bachard --qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: [Code] strategy for child works spaces
Hi Pedro, Le 18 nov. 11 à 19:26, Pedro Giffuni a écrit : Hi Eric; --- On Fri, 11/18/11, eric b eric.bach...@free.fr wrote: Disclaimer: this list is not easy to read, and if the topic was already discussed. In this case, thanks in advance to provide me the right link :-) Hi, I perfectly know the importance of the IP clearance, but in parallel, we'll need to work on the code, say partialy (e.g. vcl + sd + slideshow only). In OOo we used child work spaces in that purpose, but I'm not sure we defined something similar yet with Apache OpenOffice.org. I personally don't understand well how those CWSs worked or how they are integrated. One released version of OpenOffice.org was named a milestone. Between one milestone and the next one, we integrate several cws (the number may vary). We could summarize : milestone N + several cws's == milestone N+1 More about one cws : Formaly, this is a set of changes, based on a milestone. More precisely, a cws is a branch (not sure with the term) based on a milestone, defined during it's creation. The main idea is that the developer can commit changes without break HEAD. When the cws is confirmed ok ( e.g. the feature works, no breakage on any OS, and no known issue introduced and so on, the cws is ready for integration. At the end, was the release engineer who decided which cws's can be integrated, to define the next OpenOffice.org milestone. The drawback is, that the dev must not take a too long time to add the new code: when enough of other cws's are ok, they can be integrateed, and new milestones appear in meantime. Waiting too long means the dev will have to resync the cws with a more recent milestone, because the diff will no longer apply. FYI, one link who could help you. http:// wiki.services.openoffice.org/wiki/ChildWorkSpace I would personally prefer if just use SVN branches exclusively from now on. I think SVN branches is similar, but since code is commited a bit randomly, there is no certitude the code is the same between the time I checkout and the time I want to commit my diff. e.g. the part of the code I'm working on can be obsolete e.g. somebody modified the same files as the one I was working on. I think OOo has not really used this historically, but in other projects developers have their own branches and can do work without disrupting the main tree. I think we are discussing about the same idea :-) Obviously, some parts of the IP clearance could be achieved this way too. As I see things the absolute priority is to go through the IP clearance process and before that nothing significant will be integrated. My proposal was to organize more the IP clearance. The big question is how much will we do between the IP clearance and 3.4. There are a few CWSs that could be integrated (mst had proposed a few) and I would particularly favor gnumake4 as that would be in the direction of getting rid of dmake which we will have to do sooner or later. I'm not sure to I agree: introduce gnumake4 will introduce a lot of issues build breakers and more. That's why I'd prefer build using an old but working well tool and introduce build breakers later. I think for practical reasons, once the IP clearance is done we will replace a few of the features with free components and after that we will just do the release but any feature or even bug fixes will be left for after 3.4. More IP clearance goes, and less I see something buildable, but 'm probably wrong. This means 3.4 will have some very outdated components. I am particularly concerned about ICU, but I already made up to the idea it is unavoidable. Indeed ICU, is a nice mess. Worse: I bet a lot of the binaries we build are maybe completely useless since years, and help to provide a bloated set. Right now I think the road ahead is as follows: - Continue with IP clearance only (I estimate 2-3 weeks but it's only a guess). - Once that is over we have to discuss what features can be recovered: There is one important step (I didn't see it) : we must provide robust and well working instructions to build OOo, everywhere, because what counts is the number of people building, and able to say : no problem, or there is one breaker. I remember what did the MAc os X port success : lot of people building and building again. 1) the COIN solver. 2) Update the wpdlib support? 3) Perhaps put back MySpell in addition to Hunspell. 4) Maybe update some non-critical components (ICC?). - We branch 3.4 and only do finishing touches there. trunk can start doing aggressive CWSs merging, cleanups, new features, etc. More urgent : fix crashes, and boring (for the user) issues This surely requires more discussion and thinking, but that's about all the planning I have in mind ATM. Yes, sure : let's organize a bit. Regards, Eric -- qɔᴉɹə Projet
Re: [Code] strategy for child works spaces
Hi Eric; --- On Fri, 11/18/11, eric b eric.bach...@free.fr wrote: I personally don't understand well how those CWSs worked or how they are integrated. One released version of OpenOffice.org was named a milestone. Between one milestone and the next one, we integrate several cws (the number may vary). We could summarize : milestone N + several cws's == milestone N+1 That's the main thing VCSs do. But what I read CWS started in CVS and were adapted to work similarly in SVN and Hg. If I download a CWS, will I get a diff or a code tree? The nice thing in SVN you can merge from the current code and you can keep in line with the upstream code. More about one cws : Formaly, this is a set of changes, based on a milestone. More precisely, a cws is a branch (not sure with the term) based on a milestone, defined during it's creation. The main idea is that the developer can commit changes without break HEAD. When the cws is confirmed ok ( e.g. the feature works, no breakage on any OS, and no known issue introduced and so on, the cws is ready for integration. At the end, was the release engineer who decided which cws's can be integrated, to define the next OpenOffice.org milestone. We usually do it the other way around: you first merge current (trunk) into you branch, test it well, and then merge it back upstream. I still have some more reading to do in the SVN handbook but I have the impression that you guys reinvented the wheel all along :). Not that anything is too easy: FreeBSD used CVS and perforce for a long while before deciding to move to SVN and some people like git too. The drawback is, that the dev must not take a too long time to add the new code: when enough of other cws's are ok, they can be integrateed, and new milestones appear in meantime. Waiting too long means the dev will have to resync the cws with a more recent milestone, because the diff will no longer apply. FYI, one link who could help you. http://wiki.services.openoffice.org/wiki/ChildWorkSpace Thanks, this is a summary of how this has worked for FreeBSD: http://youtu.be/66enuplpZxw so I expect this is basically the same issue, but at a different level. I would personally prefer if just use SVN branches exclusively from now on. I think SVN branches is similar, but since code is commited a bit randomly, there is no certitude the code is the same between the time I checkout and the time I want to commit my diff. e.g. the part of the code I'm working on can be obsolete e.g. somebody modified the same files as the one I was working on. This is never easy but SVN does help: it knows when files have moved or if some simple changes still apply. I think OOo has not really used this historically, but in other projects developers have their own branches and can do work without disrupting the main tree. I think we are discussing about the same idea :-) :). Obviously, some parts of the IP clearance could be achieved this way too. As I see things the absolute priority is to go through the IP clearance process and before that nothing significant will be integrated. My proposal was to organize more the IP clearance. IP clearance is one a life time thing and it's the great bottleneck for a release at this point. I think the wiki +bugzilla works well enough for now. The problem is that Wiki+bugzilla is not a sustainable development model for what follows. I'm not sure to I agree: introduce gnumake4 will introduce a lot of issues build breakers and more. OK, I was under the impression that gnumake4 was actually small but I can live without more stuff being integrated. That's why I'd prefer build using an old but working well tool and introduce build breakers later. OK. I do think after 3.4 we should integrate everything from Oracle that makes sense. More IP clearance goes, and less I see something buildable, but 'm probably wrong. hmm .. We are not really breaking things but we are cutting things from the build. Some changes are really nice: OOo is very bloated and getting rid of some of the GNU stuff like regex and glibc makes sense and a lot of stuff is not really used at all. Indeed ICU, is a nice mess. Worse: I bet a lot of the binaries we build are maybe completely useless since years, and help to provide a bloated set. Right now I think the road ahead is as follows: - Continue with IP clearance only (I estimate 2-3 weeks but it's only a guess). - Once that is over we have to discuss what features can be recovered: I forgot: we have to run flawfinder, a security audit tool that produces lots of false positives but that nevertheless sometimes detects some hazards. There is one important step (I didn't see it) : we must provide robust and well working instructions to build OOo, everywhere, because what counts is the number of people building, and able to say : no
