RFR: JDK-8029776 - Solaris code cleanup

[David Holmes]

On 5/03/2014 7:37 PM, Volker Simonis wrote:
> Hi David,
>
> thanks for your suggestion.
>
> Creating new bugs and closing the confidential ones as duplicates
> sounds reasonable and pretty simple.
>
> Hopefully this methodology will spread among Oracle engineers and they
> will use it BEFORE they start working on bugs which are unnecessarily
> flagged as confidential such that the webrev and the push can use the
> new, visible Bug ID.
>
> By the way, what's the exact meaning of 'confidential'. I suppose it
> is something like "Oracle internal" right? So there's no chance for
> any external contributor to ever get access to such kind of
> information.

In Jira terms "confidential" is restricted to certain "roles" in the 
project. One such role is "Oracle employee".

I can't discuss what kind of information has to be flagged "confidential".

David

> Regards,
> Volker
>
>
> On Wed, Mar 5, 2014 at 4:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>>
>>
>> On 5/03/2014 3:38 AM, Volker Simonis wrote:
>>>
>>> Hi Gerald,
>>>
>>> thanks for providing the bug description.
>>>
>>> For this bug I think that's not really a problem because the synopsis
>>> as well as the change itself are already quite straight forward.
>>>
>>> My comment was intended more as a general hint to raise the awareness
>>> such that people don't create confidential bugs if this is not
>>> absolutely necessary.
>>>
>>> Also the fact that for some reason it seems to impossible to "open" a
>>> bug which was once flagged as "confidential" seems unnecessarily
>>> restrictive to me.
>>
>>
>> Unfortunately it is a restriction imposed by the way JBS/Jira operates. Once
>> a bug is marked non-confidential any data that was ever present in a part of
>> the report that was not itself marked confidential (ie comments can be
>> confidential) will be visible in the bug history. So unfortunately once a
>> bug is confidential it generally has to stay that way. And if we
>> accidentally make something public that should be confidential we then have
>> to flag the whole bug as confidential. Though in the latter case I would
>> suggest that we should file a new open bug and close the confidential one as
>> a duplicate (that works okay for new bugs, but not for backports of course).
>>
>> David
>> -----
>>
>>
>>> All this makes it sometimes very hard for the community (but also for
>>> licensees) to understand what's going on. And this is not just the
>>> missing description during a review, but also the information when and
>>> to which repository a fix is integrated, which backports exist and so
>>> on. That's all very important and useful information for people
>>> outside Oracle which build their own OpenJDK/Java distribution.
>>>
>>> Thanks,
>>> Volker
>>>
>>>
>>> On Tue, Mar 4, 2014 at 6:18 PM, Gerald Thornbrugh
>>> <gerald.thornbrugh at oracle.com> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> The bug is not visible because it was inadvertently marked as
>>>> confidential.
>>>> Since changing it from confidential to an open state is not a reasonable
>>>> option I will just state the description of the bug fix.
>>>>
>>>> JDK-8029776 describes JDK8 Solaris specific code cleanup to address
>>>> possible unclosed file descriptors, to make array indexes more readable
>>>> and make sure functions return values.
>>>>
>>>> Does this help?
>>>>
>>>> Thanks!
>>>>
>>>> Gerald Thornbrugh
>>>>
>>>>
>>>>> Hi Gerald,
>>>>>
>>>>> the bug is not visible. Could you please fix this.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh
>>>>> <gerald.thornbrugh at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am a member of the Oracle Hotspot group and there is an initiative to
>>>>>> clean up
>>>>>> things like uninitialized variables and unclosed file descriptors in
>>>>>> JDK8.
>>>>>> This is a
>>>>>> backport of fixes that have already been putback into JDK9. I have run
>>>>>> UTE
>>>>>> and
>>>>>> JPRT tests on Solaris machines without proflems. The below webrev show
>>>>>> the
>>>>>> fixes for
>>>>>> the Solaris area.
>>>>>>
>>>>>> Bug:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029776
>>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/
>>>>>>
>>>>>> Please review my changes and let me know if you have questions.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Gerald Thornbrugh
>>>>
>>>>
>>>>
>>