Make security issues widget configurable

[InfoSec812]

Resolves #13

[davewichers]

Devon - some questions:

1. Seems like we should define a single default list (rather than 2) and they both use the same list. Can we eliminate that duplication?

2. I don't see how someone can change the configuration. I was expecting some kind of properties file that could be set to override the default settings. However its done, can a user change the defaults in one place and affect both widgets lists identically?

3. And what default values are you proposing? The same as they are now? And so I'd have turn the 2 off that I propose be off? I suspect that's the case, but wanted to make sure. I would prefer 'my' setting be the default, but if you don't like that idea I guess its fine, now that its configurable.

[InfoSec812]

So, defining a single default for both widgets would require quite a bit of re-work of the widgets (or perhaps consolidation?). You change the configuration as shown below:

1. Click on the "Configure widgets"
2. Click on "Edit"
3. Enter the tags you are interested in:

[InfoSec812]

Keep in mind that this has not yet been released, so you will not be able to test it unless you grab my fork and build it yourself.

[davewichers]

OK. Consolidating the 2 lists into 1 isn't a huge deal, just a
recommendation.

So, I was kind of expecting that you could take way items you didn't want,
but sounds like if you change the configuration, you have to specify ALL
the ones you do want, and that completely replaces the default? If so,
that's fine. A user could simply cut/paste the default, and then remove
whatever they don't want. So that's fine.

If this is all correct, then yes, please push your changes and we'll try it
out!

Thanks, Dave

On Thu, Jun 30, 2016 at 11:10 AM, Deven Phillips [email protected]
wrote:

So, defining a single default for both widgets would require quite a bit
of re-work of the widgets (or perhaps consolidation?). You change the
configuration as shown below:

1. Click on the "Configure widgets" [image: image]
   https://cloud.githubusercontent.com/assets/99691/16493287/ec9fd092-3eb2-11e6-9478-04523c844602.png
2. Click on "Edit" [image: image]
   https://cloud.githubusercontent.com/assets/99691/16493351/1dcbaccc-3eb3-11e6-97fb-93cceb7a8ba1.png
3. Enter the tags you are interested in: [image: image]
   https://cloud.githubusercontent.com/assets/99691/16493374/35ff80ca-3eb3-11e6-9de8-197124223a84.png

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AExbBZwDTrxXw7mS-X3VHyquZAkZazKrks5qQ9xmgaJpZM4JCEvl
.

[InfoSec812]

@ganncamp I'm unsure of the release process as yet... I know that before the updated plugin can got to the Update Site it will have to be reviewed by the mailing list and we have to get out release notes et. al. Which parts are automated in the TravisCI build? Do I make the review announcement and have it point to this PR before merging? Any assistance would be appreciated!

[ganncamp]

@InfoSec812, it's all on you. :-)

Your first step is to build and post somewhere a release candidate - hopefully with a list of changes in the version. Here's a good example of one way to handle that: https://github.com/SonarQubeCommunity/sonar-l10n-ko/releases/tag/1.3.0-RC3

Then open a RFF (request for feedback) thread in the Google group. Give people a deadline for response. Typical duration is 72h, but that's up to you & if it were me I'd set a longer deadline this time because of the weekend+holiday. If the period ends with no blocking feedback, respond on the thread that you're closing the feedback period and will proceed with the release.

You do the release. Post the artifacts somewhere, again hopefully with a changelog (ex https://github.com/SonarQubeCommunity/sonar-l10n-ko/releases/tag/1.2.0). Open a new GG thread to ask that the new version be added to the update center.

HTH

[InfoSec812]

Roger that!

I wasn't sure if you guys already had a process in place as I am new to

the project.

Thanks for the quick response!

Deven

On Fri, Jul 1, 2016 at 7:40 AM, G. Ann Campbell [email protected]
wrote:

@InfoSec812 https://github.com/InfoSec812, it's all on you. :-)

Your first step is to build and post somewhere a release candidate -
hopefully with a list of changes in the version. Here's a good example of
one way to handle that:
https://github.com/SonarQubeCommunity/sonar-l10n-ko/releases/tag/1.3.0-RC3

Then open a RFF (request for feedback) thread in the Google group. Give
people a deadline for response. Typical duration is 72h, but that's up to
you & if it were me I'd set a longer deadline this time because of the
weekend+holiday. If the period ends with no blocking feedback, respond on
the thread that you're closing the feedback period and will proceed with
the release.

You do the release. Post the artifacts somewhere, again hopefully with a
changelog (ex
https://github.com/SonarQubeCommunity/sonar-l10n-ko/releases/tag/1.2.0).
Open a new GG thread to ask that the new version be added to the update
center.

HTH

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAGFa-oF1-mrTKlci3TjSuLDYBzizgRyks5qRPyZgaJpZM4JCEvl
.

[davewichers]

Deven,

When you are you going to merge this pull request in and publish the updated version of this widget?

-Dave

[InfoSec812]

Dave,

Sorry, life is in the way right now. I will try to get to it as soon as

I can.

Deven

On Aug 16, 2016 12:33 PM, "Dave Wichers" [email protected] wrote:

Deven,

When you are you going to merge this pull request in and publish the
updated version of this widget?

-Dave

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGFa5yVINAd9y2_2rqwzMWifOZ_Ip1Xks5qgeZNgaJpZM4JCEvl
.