Re: [native-lang] Update: Sun/NLC meeting

Hi,

Christian Lohmaier wrote:
> On Thu, Jun 02, 2005 at 01:48:12PM +0200, Charles-H.Schulz wrote:
> 
>>[...] 
>>As a side note, it seems to me that these issues could best be handled
>>by the ESC. I hope this will be efficient in dealing with these issues.

Maybe we should ask the ESC whether it is ready for this. In any case we 
should define some defined steps and adressees for escalating issues and 
document that in a visible place.

>>If an issue is marked as "wontfix" by Sun, any developer/company should
>>be able to work on it and contribute its implementation/patch back to
>>the central trunk or at least leave it on a cws until a final decision
>>has been taken.
> 
> 
> No, better agree on consisten usage of the resolution.
> 
> wontfix should mean: Not possible at all due to technical reasons and/or
>         issue will not be incorporated even when a patch exists (product
> 	policy/strategy, legal issues, etc.).
> 

I agree.

> So it doesn't really make sense to work on it before the situation is
> cleared in the second case ("don't want this in the product") unless you
> want to maintain a patch-set against the original sources...
> 
> issues that won't be dealt with by Sun because of workload, bad
> effort/gain ratio, of no interest because StarOffice has commercial
> replacement, ... ("We won't implement it, but just go ahead and povide a
> patch") should not be closed wontfix but "worksforme" with TM
> "OOoPleaseHelp" (unless there is a dedicated resolution for this kind of
> stuff)
> 

I don't agree that they should be closed. An issue that is closed to me 
is gone. I would exclude it from any queries, except post-mortem 
statistical evaluations.

It might be assigned to a dummy owner and/or we might use the useless 
RESOLVED-LATER status for it, but we should not close it.

The most important characteristic of such an issue is that
- it is OPEN
- it has target milestone OOoPleaseHelp

Ciao, Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         [email protected]
OpenOffice.org Configuration          http://util.openoffice.org