Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 22.06.2010 16:52, Philipp Lohmann wrote: Hi, On 6/22/10 2:49 PM, Bernd Eilers wrote: Mathias Bauer wrote: That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) Name calling aside: what about issues concerning extensions ? Right now I have to move the target from the correct milestone 1 of an extension to 3.3 or some such to satisfy EIS. Which is kind of bogus. However the CWS should be 3.4 or some such since that marks into which repository code line the CWS will get integrated. one of the objective of extensions was to have an Office independent release schedule. This automatically leads to an own issue tracking and own repository, from my point of view we even can have a simplified development process, since all the cws handling was introduced not to break office code. So I would leave it to the developers of the extension whether they want to have cws or another model. Sane extensions can't break office code ! Extensions, please break out of the Office workspace, Just my 2 cents, pl +2 cent, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 23.06.2010 00:13, Mathias Bauer wrote: On 22.06.2010 14:49, Bernd Eilers wrote: Mathias Bauer wrote: Hi, Hi, the right solution would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as failed? Because the data of the issue doesn´t match the data of the CWS and we have an inconsistent state in the tools that document what we are doing. Where is the point of not wanting to also change the issue data if the decision when to fix the issue did change. Why do you want to refuse to document that by changing the issue data. The failed status in this case is just a hint to the developer that there are issues on his CWS which either need to be fixed on another CWS which is based on another codeline or which need to be adjusted to be fixed on another target which might eventually also need an agreement about that with other stakeholders involved. That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) That's complete nonsense. Setting a target to an issue or CWS can be done short before or even after a CWS is integrated. If you ever had to change the targets of issues or CWS just because you had set them to the allowed target but then - when the CWS did not make it into the release - had to change it again, you might understand why I think that is bureaucratic humbug. The target release of an issue or CWS *before* it gets integrated is unrelated to what is documented or even to what exactly ends in the release. In a train model you never know the time of arrival exactly before the train really arrives. So a target release is just a declaration of what is aimed for, nothing else. Why else are we retargetting so much issues each and every release? From my experience from the 10 past years we should only set the target milestone when the code actually get integrated. From my point of view we should only set target milestones for regression issues and stoppers only. Nevertheless I think a cws should only be integrated if all issues have the right milestone set, so that we can track with Issuezilla what actually got into the release. Making this random will lead that the target milestone will randomly set. I will set the nomination right anyhow for 3.4 for release management only, so these people will be the only one to fight their bureaucratic humbug theirself :-). Martin Ciao, Mathias - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
Hi, the right solution would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as failed? That's exactly what Stephan said: bureaucratic humbug. The check for all tasks fixed is another story. It makes sense to check that before a CWS is waiting for QA approval. Regards, Mathias On 21.06.2010 12:00, Bernd Eilers wrote: Hi there! I think the real root cause is that the definitions of what can be done on which codeline is currently often not done early enough. As soon as a new target is being created for the bugtracking system the corresponding rules should be configured in EIS also. If that would be the case we wouldn´t have any annoyance either. If that doesn´t work somebody just has to complain to the group of people which have been assigned to do these administrative tasks and that is program management. Doing such test only when the cws is being set to ready for QA just because some developers don´t like to see the color red is IMHO not the right solution. On the contrary I would argue that maybe even setting the CWS to ready for QA shouldn´t be allowed at all if there are tasks with the wrong target. Kind regards, Bernd Eilers Mathias Bauer wrote: Hi, ACK. If we think that we need that bullshit, the status should at least not be set to failed before the CWS is ready for QA. That still would be bureaucratic humbug (because both fields are that per se), but at least some humbug that is less annoying. Regards, Mathias On 18.06.2010 12:06, Stephan Bergmann wrote: What a heap of bureaucratic humbug. -Stephan On 06/18/10 11:43, Bernd Eilers wrote: Hi Stephan! There is no error in EIS, EIS behaves just as it was instructed to do. If you click on the Details link you will find the following information: - The release of this ChildWorkspace is OOo 3.4 . The release of the CWS is invalid. The allowed Releases for the MasterWorkspace of this CWS are: OOo 3.1 , OOo 3.2 , OOo 3.1.1 , OOo 3.3 , OOo 3.2.1 The List of allowed Releases for MasterWorkspaces is being maintained by program management. - This all basically means that if you think OOo 3.4 should be in the list for that MasterWorkspace but isn´t ask your friendly program manager next door to add it. Kind regards, Bernd Eilers Stephan Bergmann wrote: For a CWS based on DEV300 with release set to OOo 3.4 and all associated tasks having target OOo 3.4, AllowedRelease and AllowedTaskTargets erroneously are both set to failed (e.g., see http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=9434OpenOnly=falseSection=All). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- 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...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
Hi, On 6/22/10 2:49 PM, Bernd Eilers wrote: Mathias Bauer wrote: That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) Name calling aside: what about issues concerning extensions ? Right now I have to move the target from the correct milestone 1 of an extension to 3.3 or some such to satisfy EIS. Which is kind of bogus. However the CWS should be 3.4 or some such since that marks into which repository code line the CWS will get integrated. Just my 2 cents, pl -- If the designers of X-window built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that. -- From the programming notebooks of a heretic, 1990. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
