Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Kohei, To start with your last remark ( I'm very very confused. ): I do not want you guys to stop improving code, change thing for the better etc. On the contrary: I do applaud it. I know that you are aware of the risks of the necessary changes and do all that is reasonable to avoid it. I do not criticize the way you work either (I've no idea on what bases I could do that, given the different skills-set) (And maybe superfluous: there is no sarcasm intended in these mails, and my arguments, words.) Kohei Yoshida wrote (13-09-11 01:02) On Tue, 2011-09-13 at 00:23 +0200, Cor Nouws wrote: + always a trade-off between quality, community fun, pace of development (Michael) No real argument. I am more interested in the question: do we want avoid another 3.4-style release? So, our memory is getting rustier about how the 3.4.0 release went. Could you refresh our memory as to what exactly were the issues concerning the 3.4.0 release? I assume here that by 3.4-style release you mean the actual 3.4.0 release. PR wise, it was a bad situation. Just to bad overall quality. And that is something that I (and many others) are sadly confronted with directly. It's much easier to discuss specific issues than vague let's avoid the 3.4-style release style of argument. Many/most of the issues have been solved in the mean time of course. The thing is, that we should avoid another minor release with the quality as 3.4.0. You and I and others here can not the point-zero principle. That does not mean that a bad point zero release will bring bad PR. - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. I have deep respect for the work of Kohei, Eike and Marcus. But they do change a whole lot of stuff these days, weeks, months. Is it strange that we have to expect quite some unexpected side effects? So, you want us to stop writing code? On a serious note, any developers worth his/her money are aware that making changes may introduce side effects. There is no way to avoid it. What we do is that, given that possibility, balance out the necessary code change *and* avoiding regressions, and do our due diligence to test our code. Even with that, some things break in some unknown corner case scenarios. So we rely on testers to weed out those weird corner cases that we had not anticipated. To me that's just the normal course of business. We also help each other out by code review, and also fix each other's bugs. All great - see my introduction in this mail. Plus, we are not even hitting the code freeze (Dec 5), so I don't think it's fair to start blaming us for the necessary code changes, unless you want this project to stagnate to a stand-still way before hitting the code freeze. Again: I don't blame you for anything. I want to avoid a situation that is as bad with 3.4 release. Some essential things are better in control now. Some are not. And how does the overall picture for 3.5 release look. That is what I attempted with my post from 2011-09-06, 20:41 UTC: gathering items that have influence on the situation. Maybe that was wrong, and should I started creating a list of actual problems? We cannot on the one side complain that the old code is quite filled with oddities, mistakes, redundancies etc etc, and on the other hand do light on the risk of side effect with large code changes Oh come on. Save us the lecture there. We are all aware of the risks of large code changes. So we are limiting that until we hit a code freeze. Isn't that reasonable? I'm very very confused. Hope I have made my concerns a bit more clear now. But, considering your reply: must I conclude that you would not be happy with a possible decision on a changed freeze made at the LibreOffice conference? Kind regards, Cor -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
On Tue, 2011-09-13 at 08:26 +0200, Cor Nouws wrote: Hope I have made my concerns a bit more clear now. Not really, I'm probably in the same boat as Kohei and somewhat confused by the whole thread. Maybe we need *shorter* emails that don't try to be polite ;-) Problem at the top, proposed solutions afterwards. I think 3-5 will be a crap release because there's too many changes that I don't think we'll be able to test between now and release, is that the summary ? or I believe 3-4 was a crap release because of X, Y and Z, I think we can avoid that by D. I never felt we got specifics on the 3-4 was bad. I'm not saying it was awesome, just to hard to get a handle on something nebulous. One possibility is that it was stuff like the dictionary-upgrade failure on windows. That was pretty gruesome I suppose. So to try and avoid getting caught by windows-specific bugs we are now making windows dailies available. That should help on that front anyway. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Caolán, Caolán McNamara wrote (13-09-11 12:30) On Tue, 2011-09-13 at 08:26 +0200, Cor Nouws wrote: Hope I have made my concerns a bit more clear now. Not really, I'm probably in the same boat as Kohei and somewhat confused Ah good to read. Real devs never are good in understanding my more abstract communications :-) by the whole thread. Maybe we need *shorter* emails that don't try to be polite ;-) Problem at the top, proposed solutions afterwards. So: I have seen no data that convinces me that there is enough time between feature freeze and release to ensure reasonable quality. And I have reasons to be cautious, because I know how hard it is to make time free for good testing and reporting + that we see so little LOMaster bugs being reported, which I consider a sign of lack of attention, rather than a sign of absence of bugs. Thus the solution is: earlier feature freeze. That is short .. however, maybe I overlook some data/facts, and have a wrong understanding of the situation. (Therefore my apparently to complicated attempt to get first a mutual understanding of the playing field etc.) I think 3-5 will be a crap release because there's too many changes that I don't think we'll be able to test between now and release, is that the summary ? or I believe 3-4 was a crap release because of X, Y and Z, I think we can avoid that by D. Ah yes, short too. I choose the first. But that is neither my style, nor my belief - only my fear. I never felt we got specifics on the 3-4 was bad. I'm not saying it Devs experince this different from people in marketing and l10n groups, IMO. ( So to try and avoid getting caught by windows-specific bugs we are now making windows dailies available. That should help on that front anyway. which is great! ) -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
On Tue, Sep 13, 2011 at 2:42 PM, Cor Nouws oo...@nouenoff.nl wrote: Thus the solution is: earlier feature freeze. I disagree that this is _the_ solution. we could feature freeze today... and that would not change a things unless QA is actually done... and reciprocally, there is no need for a feature freeze to start doing serious QA work... that is, even if a couple of feature were to be integrated in the 2 or 3 weeks you may want to extend the freeze, that still would translate in 95%+ of the code untouched in these 2 to 3 weeks. That is why I mentioned what mmeeks translated into a 'slushy freeze', that is a period pre-official freeze where we self-impose an elevated attention to commit breakages or a 'quiet period' if you will, where emphasis is on bug fixing... in counterpart we need to get QA used to QA master. Heck I even thing we could function that wall all the way to RC1 (and use the notion o 'beta' just as a 'state of affair' buzzword, but still on master) If someone really want to commit invasive/dangerous things in the pre-RC period, then they should do a feature branch until we branch for RC1. at RC1 you get 2 full weeks to do a formal QA campaign, and then go on weekly RC... Again with QA using daily build to verify asap that bug are closed... If continuous QA was paid attention to, the formal RC1 QA should be mostly a matter of verifying that things do still work. I strongly believe that the best way to have a quality release is to have a process that tend to make RC1 QA an acceptance test rather than a 'let's start finding the bugs' starting point, which I feel is pretty much what happened for 3.4... Granted for the 3.4 release, master has seen pretty invasive change quite shortly prior to the official branching for beta ( due to m106 merge mostly), so certainly the dev side of the house made it very hard for QA to kick in gear in a timely manner but we will _not_ have that again for 3.5. (actually it has become very very unlikely that we will have any kind of massive merge anymore. any works pulled from an old CWS or AOOo -- if they start coding something useful -- will necessarily be in the form of patch series with limited functional scope) What the QA team can do this time around though, is not hold a grunge against the mistake that were done in 3.4 and em-brass the goal that master be 'should deliverable every day' (1). Of course that is an extreme requirement... but the idea behind this motto is that we should aim to be in a position such that at any given day, we could decide to branch a RC1 for the next version. The elephant in the room to make that (and quite frankly any other QA approach) a viable reality is automated testing. These are hard, and even harder when GUI is involved, but they are well worth it. Stephan Bergmann just took up the goal of getting subsequent tests running again into daily build.. that is a great step in the right direction... Norbert (1) that is why I do not give to much weight to the objection about 'moving the freeze date'. We choose a fairly rapid release schedule, if a feature cannot make it into one release... it will make the next one... six month later... it is not like missing the cut-off limit means 2 to 3 years delay anymore... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Norbert, Norbert Thiebaud wrote (13-09-11 23:48) On Tue, Sep 13, 2011 at 2:42 PM, Cor Nouwsoo...@nouenoff.nl wrote: Thus the solution is: earlier feature freeze. I disagree that this is _the_ solution. we could feature freeze today... and that would not change a things unless QA is actually done... and reciprocally, there is no need for a feature freeze to start doing serious QA work... that is, even if a couple of feature were to be integrated in the 2 or 3 weeks you may want to extend the freeze, that still would translate in 95%+ of the code untouched in these 2 to 3 weeks. I agree with you. That is why I mentioned what mmeeks translated into a 'slushy freeze', that is a period pre-official freeze where we self-impose an elevated attention to commit breakages or a 'quiet period' if you will, where emphasis is on bug fixing... in counterpart we need to get QA used to QA master. Heck I even thing we could function that wall all the way to RC1 (and use the notion o 'beta' just as a 'state of affair' buzzword, but still on master) If someone really want to commit invasive/dangerous things in the pre-RC period, then they should do a feature branch until we branch for RC1. at RC1 you get 2 full weeks to do a formal QA campaign, and then go on weekly RC... Again with QA using daily build to verify asap that bug are closed... If continuous QA was paid attention to, the formal RC1 QA should be mostly a matter of verifying that things do still work. OK. I strongly believe that the best way to have a quality release is to have a process that tend to make RC1 QA an acceptance test rather than a 'let's start finding the bugs' starting point, which I feel is pretty much what happened for 3.4... Granted for the 3.4 release, master has seen pretty invasive change quite shortly prior to the official branching for beta ( due to m106 merge mostly), so certainly the dev side of the house made it very hard for QA to kick in gear in a timely manner but we will _not_ have that again for 3.5. Indeed, that is a difference on the positive side. On the other side, at this stage more fundamental changes in the code base are going on (at least that is my impression). What the QA team can do this time around though, is not hold a grunge against the mistake that were done in 3.4 and em-brass the goal that master be 'should deliverable every day' (1). I do not have the idea that there is a negative sentiment in the current work, due to the un-lucky circumstances with 3.4 Of course that is an extreme requirement... but the idea behind this motto is that we should aim to be in a position such that at any given day, we could decide to branch a RC1 for the next version. That would be a sort of perfect balance between development and QA. And of course the whole discussion is about that: the balance. That of course was part of the initial discussion too (1). We can't however trust that just saying we need more QA etc is enough. And I know the good work that is going on on that front, and I also trust that we grow better gradually. Maybe I am a bit conservative in my expectations. And that also has to do with the balance in my feeling what I know from working many years with early versions, what I see under my fingers etc. And because of balance: indeed a longer time for QA, or earlier feature freeze of course can not be _the_ solution. In previous mails in this thread I already mentioned some things that we can do to try to get more QA at the right time. But again repeating my self: I know how hard it is to have enough time available for that work. And with more daily releases present, we can do better testing, but it also demands for more available time. (So when Ubuntu's Scot James expects better results with monthly releases, he probably puts a heavy burden on the QA community (2) I really start to wonder what Rainers indea is on this subject. The elephant in the room to make that (and quite frankly any other QA approach) a viable reality is automated testing. These are hard, and even harder when GUI is involved, but they are well worth it. Stephan Bergmann just took up the goal of getting subsequent tests running again into daily build.. that is a great step in the right direction... One of the many good things that we can see that is going on :-) Regards, Cor (1) that is why I do not give to much weight to the objection about 'moving the freeze date'. We choose a fairly rapid release schedule, if a feature cannot make it into one release... it will make the next one... six month later... it is not like missing the cut-off limit means 2 to 3 years delay anymore... 1) http://lists.freedesktop.org/archives/libreoffice/2011-June/014201.html 2) http://netsplit.com/2011/09/08/new-ubuntu-release-process/ -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi, [Please *first read my next mail* on this list !] Let me also reply on the minutes of tech. steering call: from Re: [Libreoffice] minutes of tech. steering call ... Michael Meeks wrote (08-09-11 17:28) + Cor's considerations on release timing Better: time available between Beta1 / RC1 and release. + existing schedule is here: http://wiki.documentfoundation.org/ReleasePlan#3.5_release + very vague, lots of factors and no data / heuristics (Thorsten) That is by intention. As written: Goal: take a clear look at what influences the development and QA of 3.5.0, in order So I wanted to gather the areas of interest first, rather then examples for every item. Sorry if that was not clear, or not inspiring ;-) + could try a slushy feature-freeze on master around an earlier release with new features (Norbert) Sounds interesting. + some new features have good QA coupling with their own builds eg. Jean Baptiste (Cedric) Some ... I think it would be good to know on which features that is and on which not. (BTW, I do like that co-operation ! ) + lots of reasons already provided why next time would be better quality-wise than last time (Michael) Looks rather unspecified and does not wipe away remaining/new reasons. + not too late to discuss at the conference and move freeze dates by a week or two (Norbert) Do all working on features agree? + always a trade-off between quality, community fun, pace of development (Michael) No real argument. I am more interested in the question: do we want avoid another 3.4-style release? + Release mgmt (Petr) + concern wrt. bugs in master - need some focus there + no more releases until after the conference + QA update (Rainer) + master in v. good shape currently modulo a few annoying bugs + eg. PDF export from writer completely broken Only few annoying bugs might as well mean that too few people work with master.. I file some, post some on IRC/dev@. (But also come across problems that are so time-consuming to try to make understandable / reproducible, that until now I did not.) Rainers does master-bugs. Mow many others do? We have to be careful for a 'I see no problems so there are no problems' trap. + monthly bug hunting session last week: + not so successful Alas. And not a signal that adds trust. Cor Nouws wrote (06-09-11 22:41) [resend of my post from 2011-09-04, 20:38 UTC with one little change] Obviously, my more conceptual approach did not work. So this time, I will try to add some more content. So, items that come to my mind: - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. I have deep respect for the work of Kohei, Eike and Marcus. But they do change a whole lot of stuff these days, weeks, months. Is it strange that we have to expect quite some unexpected side effects? We cannot on the one side complain that the old code is quite filled with oddities, mistakes, redundancies etc etc, and on the other hand do light on the risk of side effect with large code changes Same for other devs / area of development. - How much time can one annoying bug ask? Two day, two weeks? (many bugs show that is can be very time consuming) - what is the progress in the weak spots in our attention? Base e.g. Base, Windows, Mac - what can we expect for new large code chunks in the coming months or integration of some older CWS'es there will be, isn't it? - the increase in the number of people available for testing - how many people start working/testing with master/nightly builds? - how many issues see we from there? - and how fast are those solved? - development in the quality and the use of tools for testing - is attention in testing well spread over Windows / Linux / MacOS ? Do we see more or about the same activity by testers? Growth or decline in bugs? I read (about) bugs in BugZilla sometimes, that are annoying and regressions, yet did not make it to one of the most annoying gathering issues, and without doubt partly because of lack of attention of QA, either hard to simply reproduce. Compatibility with older versions, older document, ... - are there other releases/tasks that need attention during that time ? - how many people are available for beta-RC testing and fixing bugs ? e.g. the time of the year (Christmas, Western New year) Does it really make sense to have one release on Dec. 23 and the next one on Jan 6th? - can we attract
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi, from Re: [Libreoffice] minutes of tech. steering call ... Michael Meeks wrote (08-09-11 17:28) + not too late to discuss at the conference and move freeze dates by a week or two (Norbert) If it is true that ... none of the devs have working of features has problems with : - a possible decision on/around October 14; - for a change of the feature freeze date (from say December 5th to 2 or 3 weeks earlier) (so that means from appr. 7 weeks back to appr 4 weeks) .. then please read my previous mail as some context for the discussion at the conference. If not, please consider the content of that mail now. Thanks -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
On Tue, 2011-09-13 at 00:23 +0200, Cor Nouws wrote: + always a trade-off between quality, community fun, pace of development (Michael) No real argument. I am more interested in the question: do we want avoid another 3.4-style release? So, our memory is getting rustier about how the 3.4.0 release went. Could you refresh our memory as to what exactly were the issues concerning the 3.4.0 release? I assume here that by 3.4-style release you mean the actual 3.4.0 release. It's much easier to discuss specific issues than vague let's avoid the 3.4-style release style of argument. - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. I have deep respect for the work of Kohei, Eike and Marcus. But they do change a whole lot of stuff these days, weeks, months. Is it strange that we have to expect quite some unexpected side effects? So, you want us to stop writing code? On a serious note, any developers worth his/her money are aware that making changes may introduce side effects. There is no way to avoid it. What we do is that, given that possibility, balance out the necessary code change *and* avoiding regressions, and do our due diligence to test our code. Even with that, some things break in some unknown corner case scenarios. So we rely on testers to weed out those weird corner cases that we had not anticipated. To me that's just the normal course of business. We also help each other out by code review, and also fix each other's bugs. Plus, we are not even hitting the code freeze (Dec 5), so I don't think it's fair to start blaming us for the necessary code changes, unless you want this project to stagnate to a stand-still way before hitting the code freeze. We cannot on the one side complain that the old code is quite filled with oddities, mistakes, redundancies etc etc, and on the other hand do light on the risk of side effect with large code changes Oh come on. Save us the lecture there. We are all aware of the risks of large code changes. So we are limiting that until we hit a code freeze. Isn't that reasonable? I'm very very confused. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Cor, all, I jump to the point I would like to discuss: [...] - development in the quality and the use of tools for testing - is attention in testing well spread over Windows / Linux / MacOS ? - are there other releases/tasks that need attention during that time ? - how many people are available for beta-RC testing and fixing bugs ? e.g. the time of the year (Christmas, Western New year) - can we attract many people for beta-testing (prize for the top-5 (clear, useful) issue submitting testers ?) We need to change the way we involve the native-lang communities in our testing process. They are currently a bit lost by the quick turn over of the versions, but they are still willing to participate. So may we could focus them on specific regression testing, or specific functional testing that doesn't require a due short timeframe. I'm just back this evening, but we are thinking about it with Jean-Baptiste. I'll come later with a more formal proposal when Jean-Baptiste and me will have discussed it further. Kind regards Sophie -- Founding member of The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Sophie, Sophie Gautier wrote (08-09-11 22:38) We need to change the way we involve the native-lang communities in our testing process. They are currently a bit lost by the quick turn over of the versions, [...] Indeed, that is an extra load for the testers/ native-lang community members. Recently I read a interview with someone from Mozilla QA who mentioned the same issue. So, turning this a bit in positive direction definitely will help - regardless the outcome of this broader discussion. Jean-Baptiste. I'll come later with a more formal proposal when Jean-Baptiste and me will have discussed it further. May also be a formal suggestion ;-) Thanks, Cor -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] 3.5 release from QA to point-zero
[resend of my post from 2011-09-04, 20:38 UTC with one little change] Hi *, Some time ago there was a discussion about the release for 3.5. The sub-optimal situation with the release of 3.4.0, was food for the discussion on the 3.5 release. Quite a lengthy and interesting discussion at that time (1) I promised to get back on this issue. Goal: take a clear look at what influences the development and QA of 3.5.0, in order to make sure that we do not have the problems as with 3.4.0. I do not want discuss this because I would be convinced that it is necessary to change the planned release-schedule (2) - I am not even making that suggestion. Anyway, not now ;-) I just want to feel a bit comfortable with what we are going to do. So it is good to make a clear picture of the situation, of the items involved. I will make a list (not pretending that it is comprehensive) below. However, of course it is very unlikely that such an effort can lead to some solid scientific prediction (anyway, not before the event ;-) ), it thus serves to get the information and feeling right. Which in itself is important enough. And it might lead to the conclusion that more time between freeze and first RC is needed. Which can be found in either direction of course, and of which an earlier freeze will definitely be preferred. If.. So, items that come to my mind: - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. - How much time can one annoying bug ask? Two day, two weeks? (many bugs show that is can be very time consuming) - what is the progress in the weak spots in our attention? Base e.g. - what can we expect for new large code chunks in the coming months or integration of some older CWS'es - the increase in the number of people available for testing - how many people start working/testing with master/nightly builds? - how many issues see we from there? - and how fast are those solved? - development in the quality and the use of tools for testing - is attention in testing well spread over Windows / Linux / MacOS ? - are there other releases/tasks that need attention during that time ? - how many people are available for beta-RC testing and fixing bugs ? e.g. the time of the year (Christmas, Western New year) - can we attract many people for beta-testing (prize for the top-5 (clear, useful) issue submitting testers ?) = = [ Shudder ... would one ever dare to plan any release again after this listing ? :-p ] What did I forget? Maybe some can have a major impact consider? Is it a useful approach to think a bit more in detail about these items? Also on the discussion we had before, there was a simple and sound idea from Norbert (3), worth to consider (expand the time between Beta/RC / release on Thursday / QA still need to use Daily Build) Thanks for your feedback, Cor 1) starting here: http://lists.freedesktop.org/archives/libreoffice/2011-June/014201.html 2) http://wiki.documentfoundation.org/ReleasePlan#3.5_release 3) http://lists.freedesktop.org/archives/libreoffice/2011-June/014293.html -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi, for testers it might be really nice to release alpha/beta tarballs during early stages of development cycle. This would allow at least me to add it for testing into Gentoo and I think quite few people would test it that way. I provide even live ebuild that compiles from the git, but I think there are 2-3 users of that or a bit more as people tend to avoid the live packages (specially for such large project). But, at least in Gentoo community, they really enjoy to test alpha stuff and report bugs. So we just need to give them tarballs to keep them happy :) Cheers Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi Kohei, Kohei Yoshida wrote (05-09-11 02:50) On Sun, Sep 4, 2011 at 4:38 PM, Cor Nouwsoo...@nouenoff.nl wrote: - How much time can one annoying bug ask? Two day, two weeks? e.g. https://bugs.freedesktop.org/show_bug.cgi?id=40466#c10 Hmm... I don't see the relevance of my comment in the bug to what you are stating here. What do you mean by your first statement? Sorry, I should have given more explanation with the reference to your comment, or not use it, I think. It is not to say how much time you used in this particular case (have no real idea honestly), but it is one of the various comments that shows how time consuming finding the cause of some bugs can be. But probably that statement is superfluous ;-) Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] 3.5 release from QA to point-zero
Hi *, Some time ago there was a discussion about the release for 3.5. The sub-optimal situation with the release of 3.4.0, was food for the discussion on the 3.5 release. Quite a lengthy and interesting discussion at that time (1) I promised to get back on this issue. Goal: take a clear look at what influences the development and QA of 3.5.0, in order to make sure that we do not have the problems as with 3.4.0. I do not want discuss this because I would be convinced that it is necessary to change the planned release-schedule (2) - I am not even making that suggestion. Anyway, not now ;-) I just want to feel a bit comfortable with what we are going to do. So it is good to make a clear picture of the situation, of the items involved. I will make a list (not pretending that it is comprehensive) below. However, of course it is very unlikely that such an effort can lead to some solid scientific prediction (anyway, not before the event ;-) ), it thus serves to get the information and feeling right. Which in itself is important enough. And it might lead to the conclusion that more time between freeze and first RC is needed. Which can be found in either direction of course, and of which an earlier freeze will definitely be preferred. If.. So, items that come to my mind: - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. - How much time can one annoying bug ask? Two day, two weeks? e.g. https://bugs.freedesktop.org/show_bug.cgi?id=40466#c10 - what is the progress in the weak spots in our attention? Base e.g. - what can we expect for new large code chunks in the coming months or integration of some older CWS'es - the increase in the number of people available for testing - how many people start working/testing with master/nightly builds? - how many issues see we from there? - and how fast are those solved? - development in the quality and the use of tools for testing - is attention in testing well spread over Windows / Linux / MacOS ? - are there other releases/tasks that need attention during that time ? - how many people are available for beta-RC testing and fixing bugs ? e.g. the time of the year (Christmas, Western New year) - can we attract many people for beta-testing (prize for the top-5 (clear, useful) issue submitting testers ?) = = [ Shudder ... would one ever dare to plan any release again after this listing ? :-p ] What did I forget? Maybe some can have a major impact consider? Is it a useful approach to think a bit more in detail about these items? Also on the discussion we had before, there was a simple and sound idea from Norbert (3), worth to consider (expand the time between Beta/RC / release on Thursday / QA still need to use Daily Build) Thanks for your feedback, Cor 1) starting here: http://lists.freedesktop.org/archives/libreoffice/2011-June/014201.html 2) http://wiki.documentfoundation.org/ReleasePlan#3.5_release 3) http://lists.freedesktop.org/archives/libreoffice/2011-June/014293.html -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Cor, On Sun, Sep 4, 2011 at 4:38 PM, Cor Nouws oo...@nouenoff.nl wrote: - How much time can one annoying bug ask? Two day, two weeks? e.g. https://bugs.freedesktop.org/show_bug.cgi?id=40466#c10 Hmm... I don't see the relevance of my comment in the bug to what you are stating here. What do you mean by your first statement? Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
