Re: [dev] proposal for change of cws policies
Joerg Sievers wrote: Hi Martin, Hi there! Martin Hollmichel wrote: I suggest that we make this cws policies official on July 11th if there are no objections until then. I have modified some things in the Wiki without changing or deleting the content or the meaning of it: Me too. I basically just added some missing links eg. to UX team, QA team and Documentation team pages, a link the coding guidelines, a link to the resolve merge conflicts page, added additional links for EIS, CWS and MWS and issue pages and corrected the following sentence: Coordinate with Hamburg release engineering on how to get this fixed on the master child workspace. to Coordinate with Hamburg release engineering on how to get this fixed on the [[MWS|master workspace]]. because we have only either a master workspace or a child workspace but there is no such thing as a master child workspace and in this case the master workspace was meant. PS: Will change the link in EIS for the Menu Entry Help / Policies to point to this new wiki page soon. If there are any other changes needed in EIS because of this changed policy rules just let me know the details. [...] Kind regards, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Martin Whitaker [EMAIL PROTECTED] writes: Unfortunately they will also get assertions with a vanilla build, which makes this less useful. I wasted a lot of time trying to track down the cause of an assertion, assuming it was due to a change I had introduced, before discovering it still occurred with a clean checkout. Hi Martin, I didn't say that there ain't things horribly messed in CVS HEAD. ;-) OTOH, this is not to suggest that things _are_ messed there - maybe it's just that a dev has been over-cautious... B-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, Unfortunately they will also get assertions with a vanilla build, which makes this less useful. I wasted a lot of time trying to track down the cause of an assertion, assuming it was due to a change I had introduced, before discovering it still occurred with a clean checkout. Unfortunately, not all developers pay attention to assertion nowadays. Means developers working on product builds might silently introduce assertions which then annoy others working with the non-products. So, if you strive for using non-product builds - and I'm constantly lobbying for doing so, since experience tells that a certain class of problems can be found much earlier, if you just believe the assertions -, you should always have a normal build at hand, to verify the assertions you see are not introduced by your changes. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Thorsten Behrens wrote: a product version is one that has .pro suffix at the output trees (that's the default case). A non-product has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) But be careful what you advertize: Non-Pro builds with MS VC2005 don't work before milestone m218. 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Mathias, a product version is one that has .pro suffix at the output trees (that's the default case). A non-product has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) But be careful what you advertize: Non-Pro builds with MS VC2005 don't work before milestone m218. Didn't know that - the last time I tried, non-pro builds in vanilla OOo worked. Admittedly, this was a few years ago :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
On Wed, 2007-07-18 at 22:25 +0200, Thorsten Behrens wrote: Kohei Yoshida [EMAIL PROTECTED] writes: 1) The use of product and non-product terms seems unclear to me. What do they mean exactly? Hi Kohei, a product version is one that has .pro suffix at the output trees (that's the default case). A non-product has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) Unfortunately they will also get assertions with a vanilla build, which makes this less useful. I wasted a lot of time trying to track down the cause of an assertion, assuming it was due to a change I had introduced, before discovering it still occurred with a clean checkout. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Eike Rathke wrote: Hi Martin, On Wednesday, 2007-07-04 17:04:39 +0200, Martin Hollmichel wrote: modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies http://wiki.services.openoffice.org/wiki/CWS_Policies#Build_Configurations | A CWS must be built on at least two platforms in the product version | (Windows and one UNIX platform) How will we ensure that non-Hamburg based CWSs can be built on these platforms and install sets be made available? I'm not sure about this. The intention is to avoid build breakers in the master build so I would expect that the install set for non product build must be made available. I would like to ask for comment from Release Engineering if they still need to have these rule applied. I guess it can be modified into: if any product/non product dependent code has been modified do build for nonproduct and product builds, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
On Wed, 2007-07-18 at 17:28 +0200, Martin Hollmichel wrote: Eike Rathke wrote: Hi Martin, On Wednesday, 2007-07-04 17:04:39 +0200, Martin Hollmichel wrote: modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies http://wiki.services.openoffice.org/wiki/CWS_Policies#Build_Configurations | A CWS must be built on at least two platforms in the product version | (Windows and one UNIX platform) How will we ensure that non-Hamburg based CWSs can be built on these platforms and install sets be made available? I'm not sure about this. The intention is to avoid build breakers in the master build so I would expect that the install set for non product build must be made available. I would like to ask for comment from Release Engineering if they still need to have these rule applied. I guess it can be modified into: if any product/non product dependent code has been modified do build for nonproduct and product builds, I have two comments. 1) The use of product and non-product terms seems unclear to me. What do they mean exactly? 2) IMO, requiring that the developer of the cws make the binary install set available to the QA personnel has the following downside. On Linux platform, there is an issue of ABI compatibility due to gcc versioning as well as system library dependencies. When I build on my machine, I do build using gcc 4.1.0 and make use of external system libraries. This means that, even if I am able to provide an installation set for the QA personnel by uploading it to an FTP/Web server, my install set may not run on QA person's (Linux) machine. To me, it is just as well workable (or better?) to check the integrity of a cws at source code level, and have both the developer and the QA build the same cws on both ends. I'm personally not seeing any advantage of requiring the developer to build and provide the binary install sets for QA, especially on Linux platform. I do agree the the developer of a cws should ensure buildability of that cws before handing it to the QA, and buildbot can play a major role here. But I don't agree with the install set requirement. --Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Mathias Bauer already pointed out that a operational build bot system is essential and solves the problems you mention here, we need to make this a priority, Martin 2) IMO, requiring that the developer of the cws make the binary install set available to the QA personnel has the following downside. On Linux platform, there is an issue of ABI compatibility due to gcc versioning as well as system library dependencies. When I build on my machine, I do build using gcc 4.1.0 and make use of external system libraries. This means that, even if I am able to provide an installation set for the QA personnel by uploading it to an FTP/Web server, my install set may not run on QA person's (Linux) machine. To me, it is just as well workable (or better?) to check the integrity of a cws at source code level, and have both the developer and the QA build the same cws on both ends. I'm personally not seeing any advantage of requiring the developer to build and provide the binary install sets for QA, especially on Linux platform. I do agree the the developer of a cws should ensure buildability of that cws before handing it to the QA, and buildbot can play a major role here. But I don't agree with the install set requirement. --Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Kohei Yoshida [EMAIL PROTECTED] writes: 1) The use of product and non-product terms seems unclear to me. What do they mean exactly? Hi Kohei, a product version is one that has .pro suffix at the output trees (that's the default case). A non-product has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) 2) IMO, requiring that the developer of the cws make the binary install set available to the QA personnel has the following downside. On Linux platform, there is an issue of ABI compatibility due to gcc versioning as well as system library dependencies. When I build on my machine, I do build using gcc 4.1.0 and make use of external system libraries. This means that, even if I am able to provide an installation set for the QA personnel by uploading it to an FTP/Web server, my install set may not run on QA person's (Linux) machine. To me, it is just as well workable (or better?) to check the integrity of a cws at source code level, and have both the developer and the QA build the same cws on both ends. I'm personally not seeing any advantage of requiring the developer to build and provide the binary install sets for QA, especially on Linux platform. Yep, sounds reasonable. Would need some kind of automatism on our side, to enable more people to trigger builds. But that appears to be just another case for a (specialized) buildbot... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
On Wed, 2007-07-18 at 22:22 +0200, Martin Hollmichel wrote: Mathias Bauer already pointed out that a operational build bot system is essential and solves the problems you mention here, we need to make this a priority That sounds fantastic, thank you. :-) Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Thorsten, On Wed, 2007-07-18 at 22:25 +0200, Thorsten Behrens wrote: Kohei Yoshida [EMAIL PROTECTED] writes: 1) The use of product and non-product terms seems unclear to me. What do they mean exactly? Hi Kohei, a product version is one that has .pro suffix at the output trees (that's the default case). A non-product has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) Ah, nice to know about --enable-dbgutil. Learned something new today. :-) Would need some kind of automatism on our side, to enable more people to trigger builds. But that appears to be just another case for a (specialized) buildbot... I agree. That would certainly reduce the overhead of CWS process substantially if we have something like that. Looking forward to seeing progress in this area. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Kohei, 1) The use of product and non-product terms seems unclear to me. What do they mean exactly? http://wiki.services.openoffice.org/wiki/Non_Product_Build Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http:// wiki.services.openoffice.org/wiki/CWS_Policies Several points: - I'll fix typos in the wiki directly. - I do not understand There will be no minor versions in a CWS. What it means? - The paragraph starting with Using the Environment Information... is a bit strange. Shouldn't the first part of it be bold/headline? - huge controversy: The CWS has to be consistent (code and helpcontent/documentation) vs. The Scope: how to group tasks. If the CWS contains both new feature and its respective documentation (online help), it can't be easily grouped into 1. High-impact features and 6. Documentation. Or will we allow both categorizations at once? Other than that, +1. -- Pavel Janík - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [qa-dev] Re: [dev] proposal for change of cws policies
Kohei Yoshida schrieb: If we have an automated buildbot that provides an installation set, it's a different story, though. IMHO it more or less boils down to this point. As long as we are not able to create builds for any CWS on any platform in a few hours we will always have hurdles to overcome on either side. Everything else is of minor importance. 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [qa-dev] Re: [dev] proposal for change of cws policies
Hi Michael, Michael Meeks schrieb: Hi Martin, On Thu, 2007-07-05 at 14:14 +0200, Martin Hollmichel wrote: With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies This looks like an improvement :-) thanks. Under the Setting a CWS to approved by QA - since this is something developers can do (for category B) - can you expand on the (should for bug fixes) section - Make a test specification / test case available - is there some repository of such things somewhere ? how is that done ? in what form ? can this be waived in the case that a unit test exercises the code paths ? :-) I can speak for QA on GUI level. We define 'developer issues' (like the ones in Category B) as issues, where it isn't possible to create test case specifications or write test cases for automated testing with TestTool. If my team get such issues (or CWS with such issues), we do general regression testing in the areas where the changes were done. But these issues were tested and still can be tested by another developer by code review or doing unit test or API testing. I cannot speak for Unit test or API testing on issues or CWS. But is this needed to explain in such document? Or what should be include? Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, Martin Hollmichel wrote: I suggest that we make this cws policies official on July 11th if there are no objections until then. I have modified some things in the Wiki without changing or deleting the content or the meaning of it: - We should use the common wording in the community 'issue' instead of 'task' - we have more than one specification: (functional) software specification; test case speification [I have added the links to the chapters inside the Wiki] - Bullet lists are fine but you have priorized the issue categories and I have used an ordered list to make it more clear - A bug fix? A fix is IMO the same (fixing something that goes wrong...); removed the word bug because a fix could also be something that makes an existing behaviour faster/more efficient/ - added links to QA rules, Gatekeeper, EIS, If these changes get accepted I propose to exchange the Level of impact in the EIS application accordingly to the new categorization of cws in the policies. From my point of view more clear than in the past. Cu, Jogi http://qa.openoffice.org/qatesttool http://wiki.services.openoffice.org/wiki/User:Jsi -- Sun Microsystems GmbH Joerg Sievers Nagelsweg 55Quality Assurance Engineer 20097 Hamburg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Peter, Peter Junge wrote: defined wrong. Please refer included link http://wiki.services.openoffice.org/wiki/Approve_a_CWS. Done! Cu, Jogi http://qa.openoffice.org/qatesttool http://wiki.services.openoffice.org/wiki/User:Jsi -- Sun Microsystems GmbH Joerg Sievers Nagelsweg 55Quality Assurance Engineer 20097 Hamburg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [qa-dev] Re: [dev] proposal for change of cws policies
Hi, good work, but I miss the point where it is mentioned that there must be a link to the installsets for the QA. This should not be a nice to have but a must, otherwise the QA representative has to ask the cws owner for the installsets (with the delay which maybe occurs because of different timezones etc.) or find someone who can build the installsets locally. Greetings, Oliver Eike Rathke wrote: Hi Martin, On Wednesday, 2007-07-04 17:04:39 +0200, Martin Hollmichel wrote: modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies http://wiki.services.openoffice.org/wiki/CWS_Policies#Build_Configurations | A CWS must be built on at least two platforms in the product version | (Windows and one UNIX platform) How will we ensure that non-Hamburg based CWSs can be built on these platforms and install sets be made available? The main difference compared with the old policies are * How to group task goes now much more in detail to make more clear in which cases what people are needed to review the work on a child workspace. * added more links to documentation on how to approve a CWS * removed superfluous wording and sentences. Nice work. I suggest that we make this cws policies official on July 11th if there are no objections until then. +1 (given that the platform obstacle will be sorted out or handled relaxed) I think some sections need to be checked against / merged with / link to sections of http://wiki.services.openoffice.org/wiki/CWS which in some aspects is more detailed, and in other aspects should be replaced with the new policy. If these changes get accepted I propose to exchange the Level of impact in the EIS application accordingly to the new categorization of cws in the policies. +1 Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [qa-dev] Re: [dev] proposal for change of cws policies
Hi Oliver, On Fri, 2007-07-06 at 10:07 +0200, Oliver Craemer - Sun Germany - ham02 - Hamburg wrote: Hi, good work, but I miss the point where it is mentioned that there must be a link to the installsets for the QA. This should not be a nice to have but a must, otherwise the QA representative has to ask the cws owner for the installsets (with the delay which maybe occurs because of different timezones etc.) or find someone who can build the installsets locally. This, IMHO, is a little overkill for those who work outside of Hamburg. For instance, if the QA rep is located in Hamburg, and the developer is located remotely in his own home (like myself), there are several hurdles that need to be overcome. 1) Broadband connection, especially the uplink speed. Most residential ADSL has a very limited uplink speed, and it's designed such that, when the uplink bandwidth is fully utilized, the download bandwidth becomes close to nill. This means that, when he's uploading the installation set, or someone is downloading them from a server located from his location, his net connection is effectively down, which affects his other business. 2) Server availability to upload the installation set(s). This may not be a problem for those who work within a large organization. But for a single community member from his/her own home, this can be a huge overhead. I understand that many OO.o community members are devoted enough to take care of it themselves, but we should still not take their service granted. 3) Last, but not least, if the cws in question affects only a small part of the OO.o codebase (e.g. one small-ish patch), why make this process this heavyweight? If the issue involves only one or two patches for one or two modules based on an existing milestone (e.g. SRC680_m218), it should be easy to re-use an existing build to create installation set. If we have an automated buildbot that provides an installation set, it's a different story, though. Just my 2 cents. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [qa-dev] Re: [dev] proposal for change of cws policies
Kohei Yoshida [EMAIL PROTECTED] writes: If we have an automated buildbot that provides an installation set, it's a different story, though. There's supposed to be buildbots for said platforms - number and speed of those can clearly be improved upon, though. We've had intermittent trouble with the upload feature of some buildbots, so I'm not 100% satisfied with that yet. Main issue I have with this is that the buildbots (and tinderbox as well, BTW) are part-time projects of some volunteers, so this is not (yet) part of the official infrastructure. There'll be an improved buildbot system presented at OOoCon07, and I'd hope to see a bit more interest sparked, then... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, On Wednesday, 2007-07-04 17:04:39 +0200, Martin Hollmichel wrote: modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies http://wiki.services.openoffice.org/wiki/CWS_Policies#Build_Configurations | A CWS must be built on at least two platforms in the product version | (Windows and one UNIX platform) How will we ensure that non-Hamburg based CWSs can be built on these platforms and install sets be made available? The main difference compared with the old policies are * How to group task goes now much more in detail to make more clear in which cases what people are needed to review the work on a child workspace. * added more links to documentation on how to approve a CWS * removed superfluous wording and sentences. Nice work. I suggest that we make this cws policies official on July 11th if there are no objections until then. +1 (given that the platform obstacle will be sorted out or handled relaxed) I think some sections need to be checked against / merged with / link to sections of http://wiki.services.openoffice.org/wiki/CWS which in some aspects is more detailed, and in other aspects should be replaced with the new policy. If these changes get accepted I propose to exchange the Level of impact in the EIS application accordingly to the new categorization of cws in the policies. +1 Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to this [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, On Thu, 2007-07-05 at 14:14 +0200, Martin Hollmichel wrote: With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies This looks like an improvement :-) thanks. Under the Setting a CWS to approved by QA - since this is something developers can do (for category B) - can you expand on the (should for bug fixes) section - Make a test specification / test case available - is there some repository of such things somewhere ? how is that done ? in what form ? can this be waived in the case that a unit test exercises the code paths ? :-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, Martin Hollmichel wrote: Hi, for a long time it has been already practice that not all child workspaces had to be approved by a QA Team member but also by another developer. The same applies for the involvement of the user experience Team. Together with Lutz for the user experience team and Thorsten for the QA team we review the existing Child Workspace policies on http://tools.openoffice.org/dev_docs/child_workspace_policies.html. With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies in the section 'Making the CWS Ready for QA, Approved by QA and Nominated for Integration', the role of the QA-representative is defined wrong. Please refer included link http://wiki.services.openoffice.org/wiki/Approve_a_CWS. The QA-representative is not the to do the 'necessary tests', but the person to coordinate the QA effort. This could even mean, that the QA Rep. does no testing at all, when other tasks are on higher priority to drive the process of CWS approval. [...] Best regards Peter -- Peter Junge Program Manager and Senior Engineer Open Source Technology 北京红旗中文贰仟软件技术有限公司 Beijing Redflag Chinese 2000 Software Co., Ltd. Building No.2, Block A, Huilongsen, 18 Xihuan South Street Beijing Economic-Technological Development Area Beijing, P.R.China Tel：+86-10-51570010 ext.6212 http://www.ch2000.com.cn http://www.ch2000.com.cn/english/index.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Moin Peter :-) Peter Junge schrieb: Hi Martin, Martin Hollmichel wrote: Hi, for a long time it has been already practice that not all child workspaces had to be approved by a QA Team member but also by another developer. The same applies for the involvement of the user experience Team. Together with Lutz for the user experience team and Thorsten for the QA team we review the existing Child Workspace policies on http://tools.openoffice.org/dev_docs/child_workspace_policies.html. With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies in the section 'Making the CWS Ready for QA, Approved by QA and Nominated for Integration', the role of the QA-representative is defined wrong. Please refer included link http://wiki.services.openoffice.org/wiki/Approve_a_CWS. The QA-representative is not the to do the 'necessary tests', but the person to coordinate the QA effort. This could even mean, that the QA Rep. does no testing at all, when other tasks are on higher priority to drive the process of CWS approval. You are right. I changed this part. Thorsten PS.: For me it isn't a wonder that you find this, because you was responsible to work out with a team the 'Approve a CWS' documentation. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
