Re: Doing massive source changes
On Saturday 05 of January 2013, Michael Meeks wrote: On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote: Having said that - it is something we really want to do; can we drop the published easy hack bug in this regard (or just close it) to avoid the drip of patches there ? I'm not aware of any easy hack specifically for this, people simply do it as a part of string cleanups. And note that this is not the only case where it's possible to do the change as one big patch. I think it might be possible to e.g. get rid of all CONSTASCII macros in one go as well, or convert OSL_DEBUG, and so on. Unless we want to stay with those things forever (which I hope we don't), they will be eventually cleaned up one way or another. I suggest we do it at a similar time to Norbert's onegit - ie. around the 4.0.2 release or so - when the cross-branch cherry-picking starts to reduce in frequency. Ok, it can wait for a while. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote: The patch specifically is string rtl:: prefix removal. Nice work ! :-) - wait until before 4-1 branch-off (or do not do such a big change at all) - this would mean there still would be these changes done in small bits by other people (including the gerrit review overhead) I'd be concerned about doing this on the the -4-0 branch; it also makes it hard to see what changed there now we're frozen in a given module between two git hashes. Having said that - it is something we really want to do; can we drop the published easy hack bug in this regard (or just close it) to avoid the drip of patches there ? I suggest we do it at a similar time to Norbert's onegit - ie. around the 4.0.2 release or so - when the cross-branch cherry-picking starts to reduce in frequency. Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Doing massive source changes
Hello, I have a patch that is 32M big and I rather wonder when to commit it. The patch specifically is string rtl:: prefix removal. These changes regularly show up in gerrit patches for review, but I think we have somewhat better EasyHacks for new developers than rather mindless searchreplace, and it's somewhat annoying to review such diffs as well. So instead I've done the change over the entire codebase where possible. The problem is, the change is so extensive that it touches pretty much everything (9117 files changed, 92833 insertions(+), 95662 deletions(-)). Given that we branched 4-0 a short time back, this will probably mean backporting will often need adjusting. So the options I see: - wait until before 4-1 branch-off (or do not do such a big change at all) - this would mean there still would be these changes done in small bits by other people (including the gerrit review overhead) - push now, only to master - this would mean more likely conflicts when backporting changes - push now, including to 4-0 - I can successfully do a full build, including make check, and I've avoided public API modules (sal, salhelper, cppu, cppuhelper, odk - any others?), so this hopefully should be safe, but most of the changes have been done using sed, so there may be something that I've missed Does somebody have a preference? I consider the last one to be the best option. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
Hi, I would recommend going with the last option, when i looked on the reviews it is pretty mindless search and replace so the only issue is to make sure the replace script wont bork stuff. Cheers Tom 2013/1/4 Lubos Lunak l.lu...@suse.cz: Hello, I have a patch that is 32M big and I rather wonder when to commit it. The patch specifically is string rtl:: prefix removal. These changes regularly show up in gerrit patches for review, but I think we have somewhat better EasyHacks for new developers than rather mindless searchreplace, and it's somewhat annoying to review such diffs as well. So instead I've done the change over the entire codebase where possible. The problem is, the change is so extensive that it touches pretty much everything (9117 files changed, 92833 insertions(+), 95662 deletions(-)). Given that we branched 4-0 a short time back, this will probably mean backporting will often need adjusting. So the options I see: - wait until before 4-1 branch-off (or do not do such a big change at all) - this would mean there still would be these changes done in small bits by other people (including the gerrit review overhead) - push now, only to master - this would mean more likely conflicts when backporting changes - push now, including to 4-0 - I can successfully do a full build, including make check, and I've avoided public API modules (sal, salhelper, cppu, cppuhelper, odk - any others?), so this hopefully should be safe, but most of the changes have been done using sed, so there may be something that I've missed Does somebody have a preference? I consider the last one to be the best option. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
Just a simple contributor and C++ beginner of course but I agree for the last solution. About building, it could be interesting to have the maximum of elements enabled in autogen.lastrun (all the extensions + dbgutil). Also, perhaps you won't be able to build on all env (Linux, Win, MacOs...) so we'll got to check master and 4.0 Tinderboxes and fix quickly if red (hopefully it's just quick and easy fix) However, again the last solution you proposed seems the best. Julien -- View this message in context: http://nabble.documentfoundation.org/Doing-massive-source-changes-tp4027231p4027239.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
Hi, On 01/04/2013 03:12 PM, Lubos Lunak wrote: Hello, I have a patch that is 32M big and I rather wonder when to commit it. The patch specifically is string rtl:: prefix removal. These changes regularly show up in gerrit patches for review, but I think we have somewhat better EasyHacks for new developers than rather mindless searchreplace, and it's somewhat annoying to review such diffs as well. So instead I've done the change over the entire codebase where possible. Also, I've seen that some patches on Gerrit that still introduce that rtl:: (or ::rtl::) prefix - I can't really say if in code that actually requires them or not, but I seem to recall mixed notation in some of them. Is there any way to filter those out in order to avoid future actions on this? The problem is, the change is so extensive that it touches pretty much everything (9117 files changed, 92833 insertions(+), 95662 deletions(-)). Given that we branched 4-0 a short time back, this will probably mean backporting will often need adjusting. So the options I see: - wait until before 4-1 branch-off (or do not do such a big change at all) - this would mean there still would be these changes done in small bits by other people (including the gerrit review overhead) - push now, only to master - this would mean more likely conflicts when backporting changes - push now, including to 4-0 - I can successfully do a full build, including make check, and I've avoided public API modules (sal, salhelper, cppu, cppuhelper, odk - any others?), so this hopefully should be safe, but most of the changes have been done using sed, so there may be something that I've missed Does somebody have a preference? I consider the last one to be the best option. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
On Fri, Jan 4, 2013 at 8:12 AM, Lubos Lunak l.lu...@suse.cz wrote: so this hopefully should be safe, but most of the changes have been done using sed, so there may be something that I've missed Well that is the crux of it isn't it ? Although the risk per change is small, with that many changes there are indeed a substantial chance somewhere of problems... and the only option is to revert it all... there is no practical means to narrow down where the problem might come from. that could be annoying enough in master... but on 4-0, after freeze and that close from planned release... I'm not wild about that. Norbert PS: a quick scrip on git log master..libreoffice-4-0-0.beta2 indicate that, out of all the 277 patch specifc to the 4.0 branch, 39 have touched line that contained 'rtl::' and therefore _could_ be in conflict... iow at most 1 in 5 considering that back-porting should be already made with caution and attentive review, running git mergetool on these to resolve these fairly straight forward conflict should not be too much over-head overall. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
