Re: [cross-project-issues-dev] [aeri] How To Automatically Create Bug Re

[Donát Csikós <csdonat@xxxxxxxxx>]

For me both the request reopening and the create bug report idea
sounds fine. This way there won't any point in time where the user
would feel stuck how to give feedback. Which is - if I understand
correctly - the purpose of the AERI project.

Anyway, thanks for the feedback and also thanks for the AERI project
in general. For Buildship we use it extensively and it really helped
us to understand problems and how people use our software in general.


2016-07-27 15:25 GMT+02:00 Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>:
> There is nothing yet that allows a normal user to reopen a problem. There
> are other means like auto actions that can reopen a problem as soon as a new
> incident arrives that shows an already closed error still exists in a newer
> version of Buildship. See [1] for an example.
>
> However, we (the Architecture Council, Mike, Wayne, Janet and me) discussed
> whether could give normal users anonymized read access to error reports and
> also allow them to create bug reports from them. All agreed that (given we
> do a proper anonymization), there is no reason why we should not allow users
> to create bug reports.
>
> There is, however, the risk of having users blindly clicking on “Create Bug
> Report” from their submissions page when it becomes too easy. We should
> require (anonymous) users to provide little more content manually and put a
> minimum hurdle in place so that we do not get flooded.
>
> We may also allow users to reopen a bug report with a comment - but I’m not
> sure this is a great idea.
>
> Instead, we could allow users to “request reopening” and put this into
> (weekly/daily) email digests if you like.
>
> We have many options. But there is currently nothing implemented that fully
> satisfies your need. Let’s discuss what you need and see where we go/end up
> with...
>
>
>
>
>
>
> [1] https://blog.ctrlflow.com/hidden-gems-auto-reopening-problems/
>
>
>
> On 27 Jul 2016, at 12:28, Donát Csikós <csdonat@xxxxxxxxx> wrote:
>
> I'm just trying to understand the workflow here. Let's say as an
> Eclipse user I enconunter an exception and I report it via AERI. For
> some cases I might get the response that this issues was resolved as
> invalid (no bug reports involved). Now, what if I know it is not true
> and I have an example exhibiting the problem. Can update the report or
> at least send my notes to the committers via AERI in an easy way?
>
> 2016-07-27 12:00 GMT+02:00 Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>:
>
> At the moment, they would have to put comment on / reopen the bug in
> Bugzilla.
>
> Would you like to have something "more interactive” or a different behavior?
> If so, let me know what you would like to see.
>
> FWIW,
> AERI can (in general) reopen bugs in Bugzilla.
>
> Cheers,
> Marcel
>
>
> On 27 Jul 2016, at 11:53, Donát Csikós <csdonat@xxxxxxxxx> wrote:
>
> Hi Marcel,
>
> Just a quick question: what if a reviewer incorreclty closes a report?
> Is there a way for a reporter to reopen it if they are unhappy with
> the resolution?
> Cheers,
>
>
> --
> Donát Csikós
> Software Engineer
> Gradle GmbH
> Firmensitz: Manteuffelstr. 60, 10999 Berlin, Germany
> Registergericht: Amtsgericht Charlottenburg, HRB 162310
> Geschäftsführer: Regine Dockter
> T. +49-30-609886880
> W. www.gradle.org
>
> 2016-07-22 11:29 GMT+02:00 Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>:
>
> Greetings Cross-Projects,
>
> a question that was raised by several committers (and I think might be
> relevant to some of you as well) was, how to configure AERI to automatically
> create Bugzillas from your error reports. I published a short blog post
> describing how projects can configure this behavior via an automated action
> here [1].
>
> In case you have any further question or need assistance on setting this up,
> please do not hesitate to contact me...
>
> Cheers,
> Marcel
>
>
> [1]
> https://blog.ctrlflow.com/hidden-gems-automatically-create-bugs-error-reports/
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> --
> Codetrails GmbH
> The knowledge transfer company
>
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-179-131-7721
> http://www.codetrails.com/
>
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> --
> Codetrails GmbH
> The knowledge transfer company
>
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-179-131-7721
> http://www.codetrails.com/
>
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev