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

Christian wrote:

> Because flags are often not that obvious. 

Irrelevent. 

> > i) Feature can not be implemented because of coding problems.
> > ii) Feature will not, under any circumstances be implemented by Sun.
> > iii) Feature not cost effective for Sun to implement.

> Furtheremore the categories you describe won't fit and ii) and iii) don't really make a difference.

a)  There are issues that sun has closed, and written that they will
not under any circumstances use the _submitted_ patch, or any patch
that is similar to it.

b) There are issues that Sun developers have closed, with an
explanation that it was not cost-effective for them to implement.

So just how do those flages not make a difference?

> But most important: Flags don't ease the issue-handling of the other issues. Those OOoPleaseHelp-issues would still be in the way or have to be deselected everytime. With flags this is even more difficult.

They can be used as alternatives to OOOoPleaseHelp, or go back and be
used as neither "open", nor "closed".

> Sure. The best policy is useless if people don't follow it. - But this is true for the flags as well... Setting these flags (and thus putting this issue on hold until someone grabs it) without giving an appropriate comment won't help either.

A flag that says "sun refuses point blank to implement this feature" 
even if lacks no other explanation, is a lot more useful than the
current setup where things are either closed, or reassigned, and left
in limbo, even though sun won't ever do it.

xan

jonathon
-- 
A Fork requires: 
   Seven systems with:
       1+ GHz Processors
       2+ GB RAM
       0.25 TB Hard drive space