Not really a nice comment but a real issue?

Nir Lisker nlisker at gmail.com
Fri Mar 26 21:04:49 UTC 2021


There's no question that the JBS is the way to go for handling existing
reports.

As for incoming reports, I dislike the GitHub issues as they are just a
text dump, and many reporters are not careful about giving you versions
(Java/JavaFX/OS...) or working environment details. You can help GitHub
with templates like Gradle does, but I find it still a bit shaky and
overall produces much less quality reports.
There's also the issue of transferring them from whatever system we use to
JBS, how to do it and who exactly will do it? Will the triage team at
Oracle that work on the webform work here too? It takes a lot of time to
try to reproduce a bug using (sometimes cryptic) submitter instructions.

Let's enumerate the webform issues:
1. Bugs don't immediately reappear on JBS since they are triaged internally.
2. Can't add images/attachments.
3. No submitter name for those who want the credit.
4. ???

Suppose we create our own webform:
1. We technically have credentials to forward them directly into JBS
because we have Authors (needless to say it should not be dependent on a
specific person, but for now...). Will we lose Oracle's triage team in this
case or can we tell them to have a look at these bugs (we can adda label to
mark them)?
2. We can allow attachments and transfer them directly to Jira attachments.
3. We can't credit the submitter because the Reporter field in Jira is not
editable (at least at my permissions level) and I'm getting the impression
the people who are in charge of this will not make an exception for us, but
we can add a text line with "submitted by" as a workaround.

Is it worth it? Can we do better?

N.B. As John Neffenger said about issues still coming to the old repo,
maybe we should close it so they won't be misled.

On Tue, Mar 23, 2021 at 9:35 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi John, all,
>
> Clearly, there are advantages and disadvantages to the Oracle Web form.
> It's not a black/white situation.
> We need to find a solution that combines the advantages of being accessible
> as well as not creating false expectations.
>
> I really like the JBS system, it is very powerful and flexible. For
> example, we now semi-automatically create the release notes for JavaFX
> using a script. Once you have an account there, it serves its purposes.
> But I agree, the barrier for non-JDK authors to submit a bug is too high,
> resulting in issues being reported in random places, not always in a nice
> way. Hence, I think we need to provide something easier, without giving up
> the power of JBS. Actually, I am in favor of keeping JBS as it is, as its
> benefits are mainly relevant *after* an issue is entered. The question then
> moves to *how* issues are entered, and I agree the webform isn't the best
> way for this.
> The transformation between "how" issues are created and then how they are
> tracked is currently done manually at Oracle, and that is something that
> might be done in a more open, collaborative way. It's not fun work though,
> but I agree transparency would help here, and if the JavaFX community can
> help the Oracle folks with triaging OpenJFX bugs, that sounds like a
> win-win to me.
>
> One of the things I want to avoid is a random "report" that shows part of a
> stacktrace, with the reporter not giving more information. That issue would
> then become a stale issue, giving a bad impression.
> If those issues pile up in a public issue tracker. So how do we manage
> expectations, avoiding nasty tweets like "I told them there was an issue
> and after 2 years it's still there!"
>
> In summary, I believe we need to separate a few things:
> * JBS: we use this as issue tracker, where we track, monitor, label, set
> versions, link to other issues, with different possible workflows. I think
> there is no alternative for this, and that's not needed.
> * bug-report system: I'm all in to find a more accessible way, keeping into
> account that would require work being done by the community (hence, us) for
> converting issues into high-quality JBS issues.
>
> - Johan
>
>
>
> On Tue, Mar 23, 2021 at 7:28 AM John Neffenger <john at status6.com> wrote:
>
> > On 3/22/21 3:27 PM, Philip Race wrote:
> > > I am informed that, for no reason given, the corporate IT folks will
> not
> > > allow attachment upload.
> >
> > Thank you for looking into it, Phil. It's good at least to have a
> > definitive answer. I brought this up on the mailing list three years
> > ago, too:
> >
> > Re: More community participation in JavaFX
> >
> >
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021343.html
> >
> > I eventually created those bug reports, despite all the gate-keeping. In
> > fact, I'm even starting to think there could be advantages to having
> > pull requests as the only real way to participate in the OpenJFX
> > project. A flood of easily-created issues on GitHub can be just as
> > off-putting as that Oracle Web form.
> >
> > John
> >
>


More information about the openjfx-dev mailing list