Hi Ingrid, please calm down, no reason to become upset.
Ingrid Halama wrote: >> This is a matter of how teams work. In general I would give everybody >> the credit of being able to judge whether his work imposes a huge risk >> on the product or not. > Doesn't the current situation show that this is absolutely not the case? No, this is just a situation that tells us that something goes wrong, but it does not mean that everybody in the team is throwing garbage into the master. So I would like to address this "something", but not exaggerate and put everybody under a general suspicion. >> If a team member repeatedly showed him/herself as >> unable to do that, the team should address that in a way the team sees fit. >> > Hm, I would prefer to give the team member a chance to avoid his > repeated failures and to allow and to ask him to check his changes himself. Of course! But that's something different than urging all developers to do a fixed number of mandatory tests on each and every CWS. There should be a QA person for every CWS. I would consider it enough to leave it up to QA and development members of each CWS to find out if additional testing (and which tests) can help or not. It seems that currently this can be improved ;-), so let's work on that, let's strengthen the "good forces". But a general rule for all CWS - sorry, that's too much. There is something that I heard from everybody who knows something about quality (not only software): the best way to achieve a better product quality is making the people better that create the product. Replacing the necessary learning process by dictating the people what they have to do will not suffice. Give the people the tools they need, but don't force them to use the only tools you have. >> The idea of being bound to (trapped into?) a rules set that can and must >> be enforeced all the time is not my understanding of how we should work >> together. Many problems can be solved or at least reduced by appealing >> to the "good forces" in each of us, our skills, our will to do the right >> thing and our pride about our work. Sometimes it needs some reminders, >> > The 'careful forces' are not very strong at the moment. And I doubt that > some nice reminders will bring a significant change in behavior here. > But no problem, if we significantly enlarge the stopper phase we can > live with the current behavior also. I don't want to share your miserable picture of your colleagues. So I won't answer to your cynic remarks about them. >> and rules come in handy here. But you never can't enforce all rules you >> make in a free community, perhaps you can do that in prison. The >> community as a whole must take care for the value of rules, each member >> by following them and all together by reminding others and taking action >> in cases where the rules have been violated. >> > What are those actions that are taken currently if someone has brought > to much risk to the master? This is an individual consideration that each responsible person needs to find out for her/himself. I hope that you don't want to discuss how to deal with other people's performance in public. >> But in case we are unsure, we could move a bugfix that looks too risky >> but isn't a showstopper to the next release. Instead of asking if >> > So who is 'we' in this case? Is it the developer and tester who know > their own module best? Or is it some board of extra privileged people > far away from the concrete bug? > If you believe in the good forces within all of us, then give all of us > the freedom to decide whether fixes go in! I'm not sure if I understand, but probably you are mixing things. What goes into a release first depends on priority/severity/importance, something that usually is not decided on by a single person. Once something is nominated to get into the release, I still see the reservation that the code change is too much effort or seems to be too risky at the time of integration. This indeed is something that the developer should judge, either with consulting others or not. The final decision always has to take more into account than just the risk. But judging the risk indeed should be the task of the developer. And if the developer can't confirm that it's not a huge risk, (s)he better should assume it is. > If you don't believe in the good forces then their must be clear > criteria why and when fixes or features will not make it into the release. > Anything else has the smell of arbitrary regime - or is the english term > despotism? Sorry for not being a native speaker. I think you are on the wrong track. I can't make any sense of that. Perhaps a consequence of the mixture I tried to sort out in the last paragraph? >> More testing on the master(!) would be very welcome. But on the CWS? >> This will make the "time to master" even longer and then again we are in >> the vicious cycle I explained in my first posting in this thread. >> > Maybe we could try that at least? At the moment we are in the vicious > cycle of another and another and another regression in the master. I > consider this worse. Exactly this is the vicious cycle I'm talking about. Obviously you think that doing more testing (without really knowing if the tests can help) and thus moving the point of integration nearer to the release date can make it better. I think that before we embark on additional testing we should find out if there are tests that give us confidence that they could help. That's what I expect to see as an outcome of the ongoing showstopper review. Until then I think giving more people time to act as human testers is the best we can do for now. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
