Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
I suppose the best way to fix this is to help kendy (and/or whomever) expedite the m106 merge and back-merge to master - Which will result, no doubt, in master being horribly unbuildable on Windows for some weeks. But what the heck, people who definitely need a buildable master on Windows can do a branch or checkout from some suitable point in time (like right now). Let's do it, and then merge in all remaining useful stuff from CWSes and masterfixes (just repeating a term I don't know the real meaning of here) as quickly as possible. And then finally be completely on our own, without having to worry that merging in stuff from OOo will duplicate or conflict with what you hack on. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Hi Bjoern, On Mon, 2011-05-23 at 11:40 -0400, Kohei Yoshida wrote: What we decided to do was to just commit the safe fixes to the 3-4 branch and merge them into master in one go Right. Note that many of us were (and still are?) focusing on stabilizing the 3.4 branch and didn't have a working master. So every bit of effort to reduce duplication goes a long way in such situations. Quite - the logical consequence of not doing that is either: a) cherry picking to a diverging branch without build testing or b) having to build test a fix on both master and libreoffice-3-4 There is a lot of angst about non-building master at the moment ;-) so I assume you are asking for b) - which, since it is rather more resource hungry will result in a lower quality product, and more de-motivated developers :-) [ or not ? ] Personally, I can see the attraction to doing one-shot merges of -3-4 to master, after a build test from time to time. I imagine this is why the TSC agreed this, but lets re-visit it this Thursday. Having said that - the one-off horrific delay caused by the (lack of) m106 merge, and thus the big set of missing fixes to master is deadly annoying. Naturally, it is annoying to see work fixes duplicates too - I suppose the best way to fix this is to help kendy (and/or whomever) expedite the m106 merge and back-merge to master - can you help out with that Bjoern ? indications are that it is at a promising stage anyway. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Hi Michael, On Tue, 24 May 2011 10:52:29 +0100 Michael Meeks michael.me...@novell.com wrote: Note that many of us were (and still are?) focusing on stabilizing the 3.4 branch and didn't have a working master. Which is just plain wrong and needs immediate fixing. Keeping master buildable must be as high in priority as doing that with the release branch. Otherwise we need to be honest about it and closing master during releases, because there is no value in it for either new or old developers as is. Quite - the logical consequence of not doing that is either: a) cherry picking to a diverging branch without build testing orb) having to build test a fix on both master and libreoffice-3-4 There is a lot of angst about non-building master at the moment ;-) so I assume you are asking for b) - which, since it is rather more resource hungry will result in a lower quality product, and more de-motivated developers :-) [ or not ? ] No, it is not. Volume of patches for the release branch should be low. Or at least much lower than for master. Taking ten patches, reviewing them, applying them to master, building from scratch and subsequenttesting is not more work than doing that for one patch. It is much less work than taking one patch at a time and reviewing it alone on the release branch only. A full build without ccache needs 1 hour 5 min here on average dev hardware. With ccache its down to ~15 minutes. All it needs is a bit of coordination. Leaving master mostly unattended during releases will just hurt us seriously in the long run. Hunting down issues over longer sets of changes just costs resources. What is even more expensive are the things that go in and cause issues which are totally unnoticed. Naturally, it is annoying to see work fixes duplicates too - I suppose the best way to fix this is to help kendy (and/or whomever) expedite the m106 merge and back-merge to master - can you help out with that Bjoern ? indications are that it is at a promising stage anyway. Indeed: There is little use in joining me in there as of now. However, already commited myself to merge in cws gnumake4. We will need to see what we can do with the other unmerged cws. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Hi Bjoern, On Tue, 2011-05-24 at 13:44 +0200, Bjoern Michaelsen wrote: Which is just plain wrong and needs immediate fixing. Keeping master buildable must be as high in priority as doing that with the release branch. I suggest we cool off and discuss this, in a more measured way, in the TSC meeting on Thursday, deferring until then. It would also help if you have a concrete proposal that can be discussed. Aspirations as to mandatory build-ability (on every platform?) are inspiring of course, but hard to action. It would also be good to spend some time thinking through both benefits, and critically the costs of whatever you propose, to present there. Any hard data: analysis of reported build failures on the list, and their isolated causes (where they can be identified), etc. would also be extremely useful so we have some real data to discuss. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Seems to be fixed already in a different way in -3-4 (and presumably -3-4-0) by Kohei in 06b6df6759929073e917ae0fa7e819407d3e2555 , fdo#36288: Fixed a crasher on Base on Apr 20. Why the crash still happens then, no idea. Anyway, cherry-pick fails. I guess a merge of -3-4 to master is long overdue... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Hi Tor, On 2011-05-23 at 04:52 -0600, Tor Lillqvist wrote: Seems to be fixed already in a different way in -3-4 (and presumably -3-4-0) by Kohei in 06b6df6759929073e917ae0fa7e819407d3e2555 , fdo#36288: Fixed a crasher on Base on Apr 20. Why the crash still happens then, no idea. Anyway, cherry-pick fails. I guess a merge of -3-4 to master is long overdue... Yeah, very unfortunate as it is, this has to be done after the merge of m106, otherwise we'll lose even much more work that has been already done :-( The current state is in integration/dev300_m106, I'll be grateful for any help there. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
The current state is in integration/dev300_m106, I'll be grateful for any help there. Is there any email or wiki writeup on what is the recommended workflow, etc? I would love to help, but I don't know what to do. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Sorry, got my words mixed up. What I mean was obviously: Well, the policy, at least as some of us (me included) have understood it, was that the stable branch gets merged into the development branch (master) regularly, so no need to commit fixes to both. But yeah, it does now seem safer to commit to both the stable branch and master, to avoid exactly this kind of situation. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
On Mon, 23 May 2011 06:39:52 -0600 Tor Lillqvist tlillqv...@novell.com wrote: Well, the policy, at least as some of us (me included) have understood it, was that the development branch gets merged into master regularly, so no need to commit fixes to both. But yeah, it does now seem safer to commit to both the development branch and master, to avoid exactly this kind of situation. Always commit to master, cherrypick to release, to be precise. Usually you would need to have reviews for release anyway, so pushing to master spares you the patch generation, as you can just post a link. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
On Mon, 2011-05-23 at 14:29 +0200, Bjoern Michaelsen wrote: Hi Tor, On Mon, 23 May 2011 04:52:26 -0600 Tor Lillqvist tlillqv...@novell.com wrote: Seems to be fixed already in a different way in -3-4 Why that ever been done? Fixing something on the release branch, but not on the development branch is downright stupid. Because that's what we decided to do during our TSC meeting IIRC. The premise was that we would do merge regularly into master, ~at least once per week as we did during the 3.3 release. But for some reason we haven't merged stuff into master for months for the 3.4 release, which was not expected. I even did merge of the calc repo alone because of the huge delay. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
On Mon, 2011-05-23 at 14:56 +0200, Bjoern Michaelsen wrote: On Mon, 23 May 2011 06:39:52 -0600 Tor Lillqvist tlillqv...@novell.com wrote: Well, the policy, at least as some of us (me included) have understood it, was that the development branch gets merged into master regularly, so no need to commit fixes to both. But yeah, it does now seem safer to commit to both the development branch and master, to avoid exactly this kind of situation. Always commit to master, cherrypick to release, to be precise. Usually you would need to have reviews for release anyway, so pushing to master spares you the patch generation, as you can just post a link. Note that the this review process started with the RC phase, and during the Beta phase review was not required. Plus, patch generation is super easy since all it takes is git format-patch -1 send it off as an attachment. Of course YMMV, but pushing to master, going to the cgit page and copy-n-pasting the link is not necessarily easier. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
Hi Kohei, On Mon, 23 May 2011 10:08:38 -0400 Kohei Yoshida kyosh...@novell.com wrote: Because that's what we decided to do during our TSC meeting IIRC. The premise was that we would do merge regularly into master, ~at least once per week as we did during the 3.3 release. But for some reason we haven't merged stuff into master for months for the 3.4 release, which was not expected. I even did merge of the calc repo alone because of the huge delay. Well, my understanding was that the merge from release to master is just a safety measure to make sure we are not missing something. It should be a NoOp most of the time. Maybe I got that wrong. Work should still be done on the most unstable branch IMHO and tickle down to the more stable ones (under reviews, which might be suspended in the beginning). Keep in mind this not only about dev-time (as in this case), but also people are filing bugs against master, verifying them etc. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash from forms.OGridControlModel unoapitests
On Mon, 2011-05-23 at 17:14 +0200, Bjoern Michaelsen wrote: Hi Kohei, On Mon, 23 May 2011 10:08:38 -0400 Kohei Yoshida kyoshida-et1tbqhtxzrqt0dzr+a...@public.gmane.org wrote: Because that's what we decided to do during our TSC meeting IIRC. The premise was that we would do merge regularly into master, ~at least once per week as we did during the 3.3 release. But for some reason we haven't merged stuff into master for months for the 3.4 release, which was not expected. I even did merge of the calc repo alone because of the huge delay. Well, my understanding was that the merge from release to master is just a safety measure to make sure we are not missing something. It should be a NoOp most of the time. Maybe I got that wrong. What we decided to do was to just commit the safe fixes to the 3-4 branch and merge them into master in one go, to avoid duplication of efforts, while at the same time somewhat risky fixes were to be done on master first, then cherry-pick to the stable branch (if it's deemed safe). Note that many of us were (and still are?) focusing on stabilizing the 3.4 branch and didn't have a working master. So every bit of effort to reduce duplication goes a long way in such situations. Speaking for myself, I didn't have a working master build until my assigned bugs have stabilized a bit, and I didn't want to commit to master precisely because I didn't have a means to test it before pushing. Work should still be done on the most unstable branch IMHO and tickle down to the more stable ones (under reviews, which might be suspended in the beginning). You tend to generalize a lot, while in general I agree with your view, we also have to be flexible in changing the policy to balance our resources if that's considered necessary. IMO when we have a massive flood of bug reports to deal with for 3.4, and not enough developers to handle them, we have to adopt our rules to cater to that situation. Keep in mind this not only about dev-time (as in this case), but also people are filing bugs against master, verifying them etc. Are they!? This surprises me. I also monitor the bugzill reports quite regularly and my understanding is that the majority of bugs are filed against released versions, not against master. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
