RFR: JDK-8029776 - Solaris code cleanup

[Volker Simonis]

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.

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