Hello Tom, Le dimanche 03 juin 2012 à 21:51 +0100, Tom Davies a écrit : > Hi :) > A couple of fairly obscure quotes seem relevant > 1. "If at 1st you DO succeed try not to look astonished" > 2. "If at 1st you DO succeed try something harder" > > Certainty and expectation are very different words that seem to get > muddled-up sometimes. > > Did Charles, earlier in the thread, suggest that it seems reasonable to > expect more bugs and regressions before "Service Pack 1" than after (except > in the case of XP, of course)? To me this kinda seems to relate to the 2nd > point. If there are no bugs or regressions in the 1st release then maybe we > aimed tooo low! Not enough exciting innovation!?
sigh... I'm again surprised by your absolute lack of understanding of how software development, and even software works. > > Do corporate organisations always prefer the pre-Service Pack versions or > have some had a policy of waiting until after the first service pack > release? That depends of corporate organizations. Several of them pick one release; deploys it and use it for a long time unless there's a security breach. Some others test one version (i.e the .0 or .1) and deploy the .3 or .4. There are several possible and existing scenarii. > Is it true that MS once tried to claim that SP1 was already included in the > 1st release of one of their products? Were their corporate customers happy > with the way that played out? I'm not working for Microsoft Corporation. I'm sure you have happy customers of Microsoft, and that you also have unhappy ones, with all the various nuances in between. > > Does "stable" mean "older"? No. > The 3.5.0 was released around February 12th 2012 and 3.4.6 was released over > a month afterwards in around 20th March 2012. The 3.4.5 was released just a > couple of weeks before the 3.5.0. So was the 3.4.6 just "older" or did it > have different objectives? We always have two branches, one which is more recent and comes with more features, and the one that was developed before, which has maintenance releases. Just like MS Office. Just like iWorks. Just like Windows. Just like Ubuntu. Just like Red Hat Enterprise Linux. Just like... the list is long. > This seems to tie-in with the idea of having 2 branches developing > alongside each other. But why bother with the "older" branch at all? What > is it's purpose? See my answer above. What's unclear with the distinction? > > Should we claim that the .0 releases are stable and good for corporate > organisations just because we don't know whether or not there are any bugs or > regressions yet? If we haven't been told of bugs and regressions then can we > safely assume there are none? When you cross a street, how can you be sure you won't ever get smashed by a car? Obviously, you want to walk inside the pedestrian segment of the road when the light is green for pedestrian. Yet, shit happens. Sometimes there will be a mad driver who will not stop when the light is red, and it might end up in a tragedy. Does this mean you should never cross the street? > Should we promise there are none? I don't think we ever promised there would be no bugs. > Should we recommend it for people with limited or capped download capacity? > or for large-scale deployments? See my answer about the two branches distinction. I think that we need to decide the right wording and message about what to advise, and perhaps we also need to decide whether we need to be directive about criteria to choose between the two branches. I don't think it's accurate to state that the newer branch is unstable, otherwise we would call this a developer build and we would not have an actual release. I also have the feeling that there's a kind of myopy issue when it comes to users ' feedback. The feedback we will *always* get is about bugs. We usually -and no one does- don't get feedback from happy users sending us congratulations message. We may get some, but it's clearly a minority. So instead of complaining that there are bugs and that any new release is a catastrophy, it might be useful to keep some hindsight about users' feedback and spread FUD about releases. Thank you, Charles. > > Regards from > Tom :) > > > --- On Sun, 3/6/12, Charles-H. Schulz <charles.sch...@documentfoundation.org> > wrote: > > <snip /> > > That's something that no one can say "in abstracto". 25 new features could > have no or a very limited impact on one specific module while one new > feature, the twenty-sixth , would break quite some bytes inside. It really > depends of the new code, its interactions with existing dependencies, etc. > But there's no mathematical ratio, if that's your question. > > > > > Does it also mean that a new release that has LESS new features may have > > LESS bugs and LESS regressions? Why make a release such as the 3.4.6 at > > all if it doesn't have new features? > > > Have you ever heard of "Service Pack"? :-) So instead of talking about > release, let's talk about service packs whenever we're discussing the third > digit of our release mechanism. Perhaps that would help clarify things. > > > <snip /> > > > > Would it be fair to guess that the work [on the 3.4.6] went primarily into > > fixing things? > > It's not only fair, it's accurate! > > > > > > > > The vast majority of question that arrived at the Users List (from the > > moment of the 3.5.0s release right through to 3.5.3) were able to be solved > > by simply reverting to the 3.4.6. > > > > That seems logical to me. But forgive me if I'm taking things to the absurd > point here, it just feels that what you could also say is that if we took > one pencil and a sheet of paper we would stop having any bugs at all. Don't > take it the wrong way here: falling back the previous version is a > temporary fix but it can never be the way forward. > > > > > > > > The problem IS NOT that i expect NO BUGS. When have i ever said that? > > > You do complain about the existence of bugs in every new version, and you > sound as if you expect that there will be no bugs there. > > > > The problem is that people were given unrealistic expectations. They were > > effectively told to expect few or no bugs in the 3.5.0 (and the .1 and .2 > > and .3) and told that it would have less problems than previous releases. > > Now you are telling me that was unrealistic, which is exactly what my > > cross-post was saying. Perhaps you could try reading what i said instead > > of just berating and insulting me purely because i dare to be honest. > > > > > Indeed, the 3.5 does bring new features alongside more bug fixes than the > releases from other branches, but it does ship with new bugs, and these are > of course unintended, but unavoidable until discovered and properly fixed. > > <snip /> > > You report all these disgruntled users, and I fully expect that there will be > unhappy users of about anything out there, but don't forget there are very > happy users as > well, yet, they tend not to show up on forums or mailing lists just to say > how satisfied they are. Please keep these people in mind as well. > > Best, > Charles. > > > > > > > Regards from > > Tom :) > > > > > > --- On Sun, 3/6/12, Charles-H. Schulz < > > charles.sch...@documentfoundation.org> wrote: > > > > From: Charles-H. Schulz <charles.sch...@documentfoundation.org> > > Subject: Re: [libreoffice-marketing] Fw: Re: [libreoffice-users] Re: Is > > 3.5.4 ready for business users? > > To: marketing@global.libreoffice.org > > Date: Sunday, 3 June, 2012, 13:32 > > > > Tom, > > > > I don't feel accusing people of lying is going to be very constructive. if > > anything you are displaying worrying signs of your complete ignorance in > > basic software development and it's so basic you don't need to be a > > developer. So let me put this in very clear terms for you: SOFTWARE IS > > BUGGY. IT WILL ALWAYS BE BUGGY. And yes, open source software is all about > > telling everyone about identified bugs or potential bugs. Even in a stable > > release. Why? BECAUSE SOFTWARE IS BUGGY. Even proprietary software. It's > > always the case. So what happens with asking about our two branches and > > which one is the most stable? For one thing having two branches tends to be > > the rule in software development world, not the exception. Vendors or > > projects may not always label them that way, but having a maintenance > > branch and the "up-to-date" branch is the usual method out there. The > > up-to-date branch builds on top of the maintenance branch (i.e includes > > bugfixes and security related patches) while introducing new features. > > Introducing new features usually leads to new bugs, and sometimes even > > regressions. New bugs, because, did I ever mention this? SOFTWARE HAS > > BUGS. Therefore, the new branch will have new, and often unnoticed bugs. > > That's the way it works. We don't tell lies, but 3.5.4 will have more bugs > > squashed than the 3.5.0 , but the 3.5.0 will have in theory more bugs > > squashed than, say, the 3.4.3 (the release that was before the new branch > > was released). The 3.5.x is thus not a developer branch at all, but for > > users (i.e. corporations) looking for certainty, you may indeed want to > > push for their adoption of, say, a 3.4.6 or a 3.5.4 . That's how it works. > > Remember: the 3.5.0 is stable, regular people can use it everyday just > > fine, but you know what? SOFTWARE HAS BUGS. Some of these users may be > > disgruntled. It's the way it works. Have you talked to disgruntled MS > > Office users? They complain about bugs too. We all do. So please, don't > > crosspost to the universe about the blatant lies of TDF officials when > > somebody squawks about a bug; report the bugs, or have the user become a > > bug reporter and that will actually be helpful. > > > > Thanks, > > > > Charles. > > > > 2012/6/3 Tom Davies <tomdavie...@yahoo.co.uk> > > > > > Hi :) > > > Many people are willing and even enjoy testing and trying out the latest > > > newest version especially if that means they get to play with new > > > features. There are so many of them they even have names such as "early > > > adopters". We need to attract more of them!! > > > > > > Those people are not looking for stability. They are looking for fresh > > > and exciting or just trying to stay ahead of the game and see what is > > > coming up next. > > > > > > Sell those new early releases using those aspects as the way of > > promoting > > > them. > > > > > > If you blatantly lie and tell people that the new branch is "stable" then > > > those ear4ly-adopters lose interest and go elsewhere, to other projects > > > that ARE doing new and exciting things AND telling people about it. > > > > > > At the same time, by claiming that the latest new thing IS your most > > > stable version then if/when they find regressions they wont bother > > looking > > > at previous versions. After all you have just told them there is no > > > version more stable than the one they have been given and therefore any > > > problems are NEW bugs. So, they walk away to find other products that do > > > have the functionality they are looking for and just tell people they > > know > > > that LO is just not ready yet. > > > > > > In almost all cases that got as far as the Users List those blockers were > > > solved by simply getting them to try the 3.4.6 release. The one that > > > didn't have all the regressions you would expect from a new and exciting > > > branch. > > > > > > I seem to be explaining this really badly. If i say it 1 way around > > > people think i am a jerk because of course i should expect regressions in > > > the latest software. But what if i don't want the latest? What if i > > want > > > something solid and reliable? > > > > > > The official website has been telling people that 3.5.0 and so on where > > > the most reliable when they weren't!! If it told them instead that they > > > were getting the ultra-latest then they might be happier about accepting > > > regressions and perhaps looking back for a more stable version. If they > > > are told it IS the most stable version then WHY would they look? > > > > > > > > > Now there is a question on the User List asking if the 3.5.4 is stable > > > and ready for corporate use. NO-ONE can TRUSTS the official TDF line, as > > > repeated by Italo, because it has been used so many times before and then > > > found to be false in so many cases. Which part of this line is true this > > > time and which part is a lie this time? "3.5.x is stable, although there > > > are some regressions". The 1st part tells us that it is ready for > > > corporate usage, the 2nd part contradicts that. > > > > > > However the whole discussion can be avoided by actually telling the truth > > > instead of lying about it and then trying to cover-up the lie. Sell the > > > product on what really ARE its good points (ok, and stretch it a little > > as > > > every marketing department for every product probably does). > > > > > > Regards from > > > Tom :) > > > > > > > > > > > > --- On Sun, 3/6/12, Italo Vignoli <italo.vign...@gmail.com> wrote: > > > > > > From: Italo Vignoli <italo.vign...@gmail.com> > > > Subject: Re: [libreoffice-marketing] Fw: Re: [libreoffice-users] Re: Is > > > 3.5.4 ready for business users? > > > To: marketing@global.libreoffice.org > > > Date: Sunday, 3 June, 2012, 11:07 > > > > > > 3.5.x is stable, although there are some regressions which impact on > > > some users. Of course, this is not implying that 3.5.x is perfect, and > > > we will never have a perfect software as bugs and regressions are part > > > of the process especially when you are developing new features on a 20 > > > years old code base. > > > > > > Unfortunately, as it is the case for proprietary software as well, the > > > only way to check if bugs and regressions impact your usage patterns is > > > to install the software and start using it. > > > > > > Tom Davies wrote: > > > > > > > Hi :) The 3.5.0 was blatantly not ready for business use and was not > > > > stable, as we saw from the number of problems people had on the > > > > lists, problems that were often solved by going back to 3.4.x. It > > > > was absurd to claim that 3.5.0 or 3.5.1 or 3.5.2 were stable. > > > > > > -- > > > Italo Vignoli - italo.vign...@gmail.com > > > mob +39.348.5653829 - VoIP 5316...@messagenet.it > > > skype italovignoli - gtalk italo.vign...@gmail.com > > > > > > -- > > > Unsubscribe instructions: E-mail to > > marketing+h...@global.libreoffice.org > > > Problems? > > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > > > List archive: http://listarchives.libreoffice.org/global/marketing/ > > > All messages sent to this list will be publicly archived and cannot be > > > deleted > > > > > > > > > -- > > > Unsubscribe instructions: E-mail to > > marketing+h...@global.libreoffice.org > > > Problems? > > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > > > List archive: http://listarchives.libreoffice.org/global/marketing/ > > > All messages sent to this list will be publicly archived and cannot be > > > deleted > > > > > > > > > > -- > > Unsubscribe instructions: E-mail to marketing+h...@global.libreoffice.org > > Problems? > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > > List archive: http://listarchives.libreoffice.org/global/marketing/ > > All messages sent to this list will be publicly archived and cannot be > > deleted > > > > > > -- > > Unsubscribe instructions: E-mail to marketing+h...@global.libreoffice.org > > Problems? > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > > List archive: http://listarchives.libreoffice.org/global/marketing/ > > All messages sent to this list will be publicly archived and cannot be > > deleted > > > > > > -- > Unsubscribe instructions: E-mail to marketing+h...@global.libreoffice.org > Problems? > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/global/marketing/ > All messages sent to this list will be publicly archived and cannot be deleted > > -- Charles-H. Schulz Co-Founder & Director, The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint -- Unsubscribe instructions: E-mail to marketing+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/marketing/ All messages sent to this list will be publicly archived and cannot be deleted
