EIS CWS AllowedRelease/AllowedTaskTargets Problems

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

EIS CWS AllowedRelease/AllowedTaskTargets Problems

stephan.bergmann
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=9434&OpenOnly=false&Section=All>).

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Bernd Eilers

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=9434&OpenOnly=false&Section=All>).
>
>
> -Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

stephan.bergmann
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=9434&OpenOnly=false&Section=All>).
>>
>>
>> -Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Mathias Bauer
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=9434&OpenOnly=false&Section=All>).
>>>
>>>
>>> -Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Bernd Eilers

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=9434&OpenOnly=false&Section=All>).
>>>>
>>>>
>>>>
>>>> -Stephan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Mathias Bauer
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=9434&OpenOnly=false&Section=All>).
>>>>>
>>>>>
>>>>>
>>>>> -Stephan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Bernd Eilers
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 ;-)

The need to provide information and status flags in EIS and issues is
just there to reflect what actually currently is being done and what has
been done in the past for others and for processes besides the pure
coding in development that need to be organized for creating a product.

> The check for "all tasks fixed" is another story. It makes sense to
> check that before a CWS is waiting for QA approval.
>

Well just because the CWS is flagged red while it is in development that
is not a bad thing and it doesn´t mean the test has to be postponed to
the very last momment just when the developer wants to change it´s state
to "ready for qa".

In fact that´s a quite common thing in programming to write the testcase
first and than let it fail until the changes in the implementation fix
the issue.

Regards,
Bernd

> 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=9434&OpenOnly=false&Section=All>).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Stephan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Björn Michaelsen-2
Am Tue, 22 Jun 2010 14:49:17 +0200
schrieb Bernd Eilers <[hidden email]>:

> 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.

Well, as long the CWS is in state "new", neither QA or program
management should care for it. It is still firmly in the domain of
development. And there is absolutely not reason to even _care_ and
maintain "allowed releases" or other bureaucratic stuff, as development
at this stage only cares about failed buildbots and failed tests and EIS
should behave that way. Certainly devs do not want to beg PM for adding
an allowed release so they can again have a sensible summary of the
_important_ information at this stage. Once the CWS goes RfQA it is a
different issue: this is the point where the bureaucratic stuff starts.

OTOH it might be simpler to just keep the important development info
(bots and tests) out of EIS. Thereby devs could happily ignore it while
it is irrelevant (before RfQA) and still have relevant information at
hand in that phase.

Just my heretic 2 euro cents,

Bjoern


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Philipp Lohmann
In reply to this post by Bernd Eilers
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Bernd Eilers
Philipp Lohmann wrote:
> Hi,

Hi there!

> [... snip ...]
>
> 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.
>

Testing the CWS Release setting and Issues target settings are two tests
and the release test would be OK in this case now since the 3.4 setting
is now there for the DEV300 codeline. So in this case only the later has
a problem. I think here the issue is similar as with the issue of the
first poster in this thread: If you think "milestone 1" should be a
valid task target let´s say on the DEV300 codeline which I suppose you
do than ask a program manager to configure this for EIS if it is
currently not yet allowed. This has to be done just once and than from
than on you and others can use that "milestone 1" target on issues for
the DEV300 codeline and you would not need to use a bogus setting just
to "satisfy" EIS. Bogus settings on the CWSes to "satisfy" the tooling
can not be the right solution the tools (EIS in this case) should be
configured at the right end or enhanced to reflect the actual needs instead!

> Just my 2 cents, pl
>

Kind regards,
Bernd Eilers

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Mathias Bauer
In reply to this post by Bernd Eilers
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?

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 "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Jörg Jahnke
In reply to this post by Mathias Bauer
Hi,

from my POV it's OK to go with the check as it is OK for me to remove
it. In any case, the tooling team is not in a position to simply decide
to remove it. It you would like to see the check removed, please contact
the Program Managers, who had requested this feature.

Regards,

Jörg


Mathias Bauer schrieb:

> 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=9434&OpenOnly=false&Section=All>).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Stephan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Martin Hollmichel - Sun Germany - ham02 - Hamburg
In reply to this post by Philipp Lohmann
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Martin Hollmichel - Sun Germany - ham02 - Hamburg
In reply to this post by Mathias Bauer
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: [hidden email]
For additional commands, e-mail: [hidden email]