Access to bug reports in Chromium bug tracker

[Paul Menzel]

Dear coreboot folks,

looking at change set #8214 [1], it adds a comment with a reference to
the Chromium bug tracker at <code.google.com>.

http://crosbug.com/p/29117

Unfortunately access to view that is denied to me.

Looking at some of the items already in the upstream tree, most of them
seem to be accessible though.

$ git grep crosbug
        payloads/libpayload/drivers/serial/ipq806x.c:    * See
        http://crosbug.com/p/29313
        payloads/libpayload/drivers/timer/ipq806x.c: *
        http://crosbug.com/p/28880 for details.
        src/ec/google/chromeec/acpi/battery.asl:        // a bug in the
        Linux kernel: http://crosbug.com/28747
        src/ec/google/chromeec/ec_commands.h: *
        TODO(crosbug.com/p/11223): This is effectively useless; protocol
        is
        src/ec/google/chromeec/ec_commands.h: *
        TODO(crosbug.com/p/23570): These commands are deprecated, and
        will be
        src/ec/google/chromeec/ec_commands.h: *
        TODO(crosbug.com/p/23747): This is a confusing name, since it
        doesn't
        src/mainboard/samsung/lumpy/acpi_tables.c:       * Provide
        option to enable for http://crosbug.com/p/7925
        src/soc/intel/broadwell/acpi/gpio.asl:          // Disabled due
        to IRQ storm: http://crosbug.com/p/29548
        src/vendorcode/google/chromeos/vboot.c: * crosbug.com/17017 */

So my question is, is access granted to all these bugs eventually?

Thanks,

Paul

[1] http://review.coreboot.org/#/c/8214/1/src/mainboard/google/samus/romstage.c

[David Hendricks]

On Wed, Jan 14, 2015 at 2:11 PM, Paul Menzel <
[e-mail]> wrote:
> Dear coreboot folks,
>
> looking at change set #8214 [1], it adds a comment with a reference to
> the Chromium bug tracker at <code.google.com>.
> http://crosbug.com/p/29117
>
> Unfortunately access to view that is denied to me.

We use two issue trackers, one which is public (which crosbug.com redirects
to) and one which is private. The public tracker is used by default for
most cases, unless it's known that the subject matter will involve
confidential details. The particular issue you cited was likely public to
begin with, but later moved or restricted. Restrictions to issues filed on
the public tracker are sometimes added if resolving a bug involves
discussing confidential details about a chip or product (often in the form
of logs / debug output).
> Looking at some of the items already in the upstream tree, most of them
> seem to be accessible though.
>     $ git grep crosbug
>     payloads/libpayload/drivers/serial/ipq806x.c:    * See
>     http://crosbug.com/p/29313
>     payloads/libpayload/drivers/timer/ipq806x.c: *
>     http://crosbug.com/p/28880 for details.
>     src/ec/google/chromeec/acpi/battery.asl:        // a bug in the
>     Linux kernel: http://crosbug.com/28747
>     src/ec/google/chromeec/ec_commands.h: *
>     TODO(crosbug.com/p/11223): This is effectively useless; protocol
>     is
>     src/ec/google/chromeec/ec_commands.h: *
>     TODO(crosbug.com/p/23570): These commands are deprecated, and
>     will be
>     src/ec/google/chromeec/ec_commands.h: *
>     TODO(crosbug.com/p/23747): This is a confusing name, since it
>     doesn't
>     src/mainboard/samsung/lumpy/acpi_tables.c:       * Provide
>     option to enable for http://crosbug.com/p/7925
>     src/soc/intel/broadwell/acpi/gpio.asl:          // Disabled due
>     to IRQ storm: http://crosbug.com/p/29548
>     src/vendorcode/google/chromeos/vboot.c: * crosbug.com/17017 */
>
> So my question is, is access granted to all these bugs eventually?

Issues which are closed now will almost certainly remain that way.
> Thanks,
>
> Paul
>
> [1]
> http://review.coreboot.org/#/c/8214/1/src/mainboard/google/samus/romstage.c