Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Baptiste Mathus]

I think it's actually quite useful when pinging people? Also when reading
such mentions on PRs and the likes, we immediately know it's a team. Also a
bit useful for auto-completion easiness I believe.

I will not fight for this though :). Either way is still ok for me.

My 2 cents

Le ven. 13 déc. 2019 à 19:19, Oleg Nenashev  a
écrit :

> The reason of the "team-" suffix was to follow the same convention as for
> SIGs in JEP-4 (sig-...). But I have no strong opinion, happy to remove it
>
> On Fri, Dec 13, 2019, 10:38 Ivan Fernandez Calvo 
> wrote:
>
>> I'd like to be involved also at least on the testing part
>>
>> El martes, 10 de diciembre de 2019, 12:34:05 (UTC+1), Oleg Nenashev
>> escribió:
>>>
>>> BTW, I suggest the following list of maintainers based on the recent
>>> activity:
>>>
>>>- Mark Waite
>>>- Alex Earl
>>>- Carlos Sanchez
>>>- Oleg Nenashev
>>>- Baptiste Mathus
>>>- Olivier Vernin
>>>
>>> Alternative is to just keep all members of
>>> https://github.com/orgs/jenkinsci/teams/docker/members though some
>>> contributors are not active at the moment
>>>
>>> BR, Oleg
>>>
>>> On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:

 I would like that very much

 On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev 
 wrote:

> Hi all,
>
> Right now we have a number of official packages for Docker:
>
>- https://github.com/jenkinsci/docker
>- https://github.com/jenkinsci/docker-slave
>- https://github.com/jenkinsci/docker-ssh-slave
>- https://github.com/jenkinsci/docker-jnlp-slave
>- https://github.com/jenkinsci/jnlp-agents
>
> All these repositories have different teams which define permissions/.
> In addition to that we have jenkinsci/docker and
> jenkinsci/docker-packaging-team team which also grant permissions. It is
> quite difficult to manage the repositories in the current state, and it is
> difficult to request reviews.
>
> I suggest to keep things simple and just proceed with a single team
> for the official packaging:
>
>- Introduce an official "docker-packaging-team" under umbrella of
>Platform Special Interest group which currently manages Docker 
> packaging
>- Cleanup existing teams, leave just one for all official Jenkins
>master and agent mages. Plugin Docker packaging (e.g. Remoting over 
> Apache
>Kafka, Swarm plugin) will not be affected
>- Update GitHub and DockerHub teams to reflect the changes (mostly
>jenkins4eval which grants write permissions)
>- Add new team to CODEOWNERS in all repos
>
> WDYT?
>
> Thanks in advance,
> Oleg
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkin...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com
> 
> .
>
 --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/DR9nZMRgyu8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/a2eb969d-f874-47a0-9fcc-51ed874f2128%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA-NJzBxVC3MMa95EcRCxDC0HUtZW93x89WsDR10Q9CJw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPyTVp2vF8But_A%3DN8pJ09rRi4CLzcRoopdTd4%2B_yOS_83JbVg%40mail.gmail.com.

Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Oleg Nenashev]

The reason of the "team-" suffix was to follow the same convention as for
SIGs in JEP-4 (sig-...). But I have no strong opinion, happy to remove it

On Fri, Dec 13, 2019, 10:38 Ivan Fernandez Calvo 
wrote:

> I'd like to be involved also at least on the testing part
>
> El martes, 10 de diciembre de 2019, 12:34:05 (UTC+1), Oleg Nenashev
> escribió:
>>
>> BTW, I suggest the following list of maintainers based on the recent
>> activity:
>>
>>- Mark Waite
>>- Alex Earl
>>- Carlos Sanchez
>>- Oleg Nenashev
>>- Baptiste Mathus
>>- Olivier Vernin
>>
>> Alternative is to just keep all members of
>> https://github.com/orgs/jenkinsci/teams/docker/members though some
>> contributors are not active at the moment
>>
>> BR, Oleg
>>
>> On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:
>>>
>>> I would like that very much
>>>
>>> On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev  wrote:
>>>
 Hi all,

 Right now we have a number of official packages for Docker:

- https://github.com/jenkinsci/docker
- https://github.com/jenkinsci/docker-slave
- https://github.com/jenkinsci/docker-ssh-slave
- https://github.com/jenkinsci/docker-jnlp-slave
- https://github.com/jenkinsci/jnlp-agents

 All these repositories have different teams which define permissions/.
 In addition to that we have jenkinsci/docker and
 jenkinsci/docker-packaging-team team which also grant permissions. It is
 quite difficult to manage the repositories in the current state, and it is
 difficult to request reviews.

 I suggest to keep things simple and just proceed with a single team for
 the official packaging:

- Introduce an official "docker-packaging-team" under umbrella of
Platform Special Interest group which currently manages Docker packaging
- Cleanup existing teams, leave just one for all official Jenkins
master and agent mages. Plugin Docker packaging (e.g. Remoting over 
 Apache
Kafka, Swarm plugin) will not be affected
- Update GitHub and DockerHub teams to reflect the changes (mostly
jenkins4eval which grants write permissions)
- Add new team to CODEOWNERS in all repos

 WDYT?

 Thanks in advance,
 Oleg

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkin...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com
 
 .

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/DR9nZMRgyu8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a2eb969d-f874-47a0-9fcc-51ed874f2128%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA-NJzBxVC3MMa95EcRCxDC0HUtZW93x89WsDR10Q9CJw%40mail.gmail.com.

Re: Jenkins Plugin pom (future of)

[Jesse Glick]

On Thu, Dec 12, 2019 at 4:24 PM James Nord  wrote:
> There is also the support for javascript builds, but a quick search of repos 
> showed only 29 repositories … that use this … so I would argue this is better 
> handled by documentation or another possibly another pom

29 repositories is quite a lot, I think. If this is handled by
“documentation” then we will have no straightforward way of making
sure those plugins use up-to-date mojos or best practices. And we
cannot easily use another POM as Maven does not support multiple
inheritance (without a somewhat scary extension that IDEs and other
tools would not grok). I understand your desire to simplify, but this
sounds like it could just be making more maintenance work for us
overall. No strong opinion about it though, beyond Devin’s request
that a POM update must not _silently_ cease to package JS assets.

Regarding `-DskipTests`, I would perhaps propose some profile like
`-Pquick` that skips running tests, SpotBugs, Enforcer, and anything
else that is a sort of a test: i.e., could break the build but could
not affect the content of artifacts if the build passes. I wish this
were built in to / standardized by Maven itself so that mojos and IDEs
and everything else could agree on a single flag. (Note that you still
need to _compile_ tests, at least if `no-test-jar=false`.)

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
hiding all these things from the plugin “classpath” at both compile
time and runtime. Core could then use whatever library versions it
felt like with no impact on plugins, no BOM would be needed, and those
plugins actually requiring (say) Guava would need to declare a
dependency on some version of some library wrapper plugin once they
update `jenkins.version` past the split. I do not believe there is
anything all that technically difficult here, except to the extent
that functional tests might get messy (JENKINS-41827); it is more
about summoning the will to do it and follow up with various issues
afterwards.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2_th7uMJzGsKMq4kkvSY3PRCbP%3D-EXaiSQ0ikFo7Psmg%40mail.gmail.com.

Re: Jenkins Plugin pom (future of)

[Devin Nusbaum]

Some housekeeping in the plugin POM sounds good to me.

> for my part we have a lot of properties that are overloaded in profiles 
> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
> when you know how maven works becomes surprising)

I was always a bit confused by that behavior, but never realized it was 
specific to the plugin POM. +1 for removing it.

> There is also the support for javascript builds, but a quick search  
> of
>  repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this is 
> better handled by documentation or another possibly another pom) so I think 
> this should be a candidate for removal.

I agree that given how infrequently this profile is used, it makes sense to 
remove it. I do have one concern though - If one of the plugins currently using 
the profile updates to a version of the plugin POM in which it has been 
removed, will the plugin’s build continue to work silently even though the 
produced artifacts will be broken? (I saw this happen at least once after 
https://github.com/jenkinsci/plugin-pom/pull/36 
 changed the profile used for 
this functionality)? If so, would it be possible to replace the profile with 
one that just fails the build if `.mvn_exec_node` is present to avoid this 
issue, since if downstream plugins copied the profile into their POM, it would 
make more sense for them to activate it by default anyway?

Devin

> On Dec 12, 2019, at 16:23, James Nord  wrote:
> 
> Hi all,
> 
> firstly apologies about the recent messiness with consuming the jenkins bom 
>  in the plugin-pom 
> .
> 
> For those of you that are not aware the jenkins bom is trying to solve to 
> problem of not consuming newer versions of libraries that are shipped in 
> Jenkins core as this can cause unexpected failure at runtime, and to make 
> keeping the versions used in step with the Jenkins version targeted in the 
> POM.
> 
> Now the previous attempt revealed a couple of issues mainly that you should 
> not enable dependencies in a profile when the resulting pom is to be consumed 
> later.  Also Profile activation (applies to incrementals) via 
> environment/system properties is a bad idea when that changes what can be 
> consumed/produced. The reason for this is when you want to aggregate several 
> plugins in a build to perform batch testing of all their masters and some 
> want to use one profile and others don't (but you can only set one property 
> for the whole of the aggregation).
> 
> So to get a parent that works for plugins I need to break some eggs.  And 
> this is the email about what eggs we want to also break, and which eggs are 
> created by Fabergé and are too valuable to throw away. 
> 
> for my part we have a lot of properties that are overloaded in profiles 
> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
> when you know how maven works becomes surprising), we have findbugs 
> properties as well (to cope with people that are have used a findbugs flag in 
> their build and we now use spotbugs.
> 
> There is also the support for javascript builds, but a quick search  
> of
>  repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this is 
> better handled by documentation or another possibly another pom) so I think 
> this should be a candidate for removal.
> 
> Given we are breaking eggs, I do not see a reason for the new parent not to 
> use the jenkins-bom unconditionally.
> 
> Is there any other legacy that people think can be cleaned up / removed, or 
> other points of view that people want to put forward before a PR lands as a 
> surprise?
> 
> Regards
> 
> /James
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/2ce40a15-fe85-475a-8218-255140d4e1f5%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: Q: rename a variable without breaking compatibility in the declarative pipeline

[Victor Martinez]

Sure, thanks for all the information. I've raise an issue to track this 
conversation:
- https://issues.jenkins-ci.org/browse/JENKINS-60466

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/dd1600e3-9a02-4477-9e03-f160179aecb4%40googlegroups.com.

Re: Adopt a plugin request

[Terry Moreland]

Yes that's the one,

Terry


On Fri, 13 Dec 2019, 2:38 pm Slide,  wrote:

> Is this plugin hosted in the jenkinsci org? I found
> https://github.com/jenkinsci/appspider-build-scanner-plugin. Is that the
> correct one?
>
> On Fri, Dec 13, 2019, 02:37 Terry Moreland 
> wrote:
>
>> I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
>> using either of the following git accounts.
>>
>> 
>> 
>> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
>> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
>> pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
>> github id: either my work account (preferred): tmoreland-r7 or personal
>> account: tsmoreland
>> jenkins id: tmoreland
>>
>> inclusion of both accounts is because my personal account is associated
>> with this e-mail address which could join the group while my work account
>> is restricted from joining google groups
>>
>> In case it makes any difference the current maintainer's e-mail address
>> is currently being redirected to my work account (
>> terry_morel...@rapid7.com), I cannot gain control of his github account
>> due as it's using two-factor authentication.  Nonico Bugash is no longer
>> with Rapid7 which is why I'm seeking to become maintainer
>>
>> Terry Moreland
>> terry.s.morel...@gmail.com
>> terry_morel...@rapid7.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVeuCR2tk2TP6GtqiEDZgfkY2tB8Zo6hXHZZmixR0j7WfQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjfVNFHUf2MSwY-78HN8CCEyH1xYtmYCVEvRKRfbEQxnmg%40mail.gmail.com.

Re: Adopt a plugin request

[Slide]

Is this plugin hosted in the jenkinsci org? I found
https://github.com/jenkinsci/appspider-build-scanner-plugin. Is that the
correct one?

On Fri, Dec 13, 2019, 02:37 Terry Moreland 
wrote:

> I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
> using either of the following git accounts.
>
> 
> 
> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
> pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
> github id: either my work account (preferred): tmoreland-r7 or personal
> account: tsmoreland
> jenkins id: tmoreland
>
> inclusion of both accounts is because my personal account is associated
> with this e-mail address which could join the group while my work account
> is restricted from joining google groups
>
> In case it makes any difference the current maintainer's e-mail address is
> currently being redirected to my work account (terry_morel...@rapid7.com),
> I cannot gain control of his github account due as it's using two-factor
> authentication.  Nonico Bugash is no longer with Rapid7 which is why I'm
> seeking to become maintainer
>
> Terry Moreland
> terry.s.morel...@gmail.com
> terry_morel...@rapid7.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVeuCR2tk2TP6GtqiEDZgfkY2tB8Zo6hXHZZmixR0j7WfQ%40mail.gmail.com.

Re: Adopt a plugin request

[Terry Moreland]

Apologies, I missed that part; that email is currently forwarding to
terry_morel...@rapid7.com

Terry

On Fri, 13 Dec 2019, 10:52 am Baptiste Mathus, 
wrote:

> Please also add existing/current maintainers in CC, we'll need either
> her/his/their approvals, or wait 14 days usual timeout.
> Cf. https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/
>
> On Fri, Dec 13, 2019 at 10:37 AM Terry Moreland <
> terry.s.morel...@gmail.com> wrote:
>
>> I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
>> using either of the following git accounts.
>>
>> 
>> 
>> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
>> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
>> pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
>> github id: either my work account (preferred): tmoreland-r7 or personal
>> account: tsmoreland
>> jenkins id: tmoreland
>>
>> inclusion of both accounts is because my personal account is associated
>> with this e-mail address which could join the group while my work account
>> is restricted from joining google groups
>>
>> In case it makes any difference the current maintainer's e-mail address
>> is currently being redirected to my work account (
>> terry_morel...@rapid7.com), I cannot gain control of his github account
>> due as it's using two-factor authentication.  Nonico Bugash is no longer
>> with Rapid7 which is why I'm seeking to become maintainer
>>
>> Terry Moreland
>> terry.s.morel...@gmail.com
>> terry_morel...@rapid7.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPyTVp0wiDYZX1vFtpXL21d4FUisv7BDi5M%2BbY7cAw3MMC_JKw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjeGvH7ObVajX90RmdK9CmvihqWJR8V14oREeRSsBTGW4w%40mail.gmail.com.

Re: findsecbugs in spotbugs

[James Nord]

On Thursday, December 12, 2019 at 6:28:21 PM UTC, Jeff Thompson wrote:
>
> On 12/12/19 7:10 AM, Jesse Glick wrote:
>
> On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson  
>  wrote:
>
> As I was analyzing one findsecbugs finding, I immediately recognized it as 
> SECURITY-1322 […]
> If someone had run findsecbugs a year ago it would have caught that as a real 
> vulnerability.
>
> You are referring to
> https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb
>
> I guess? If it managed to catch that, then this alone seems to justify
> turning it on. My concern was that the idiosyncratic architecture of
> Jenkins would make it hard for a generic security scanner to find
> relevant issues.
>
> Yes, that's the one.
>
> Findsecbugs is clearly biased to web applications, which makes it fairly 
> applicable to Jenkins. Some things it reports on the agent side of Remoting 
> would be important on a server. Remoting operates on both sides so it 
> requires consideration as to how or where each piece runs. There are some 
> findsecbugs rules (at least 1) that just aren't treated as a concern in 
> Jenkins. As I've been analyzing findings I've thought it would be cool to 
> have some Jenkins-specific rules for findsecbugs, spotbugs, or some other 
> tool to catch some of those idiosyncratic things. But, there's enough value 
> in the rules it does have to catch common things. We should move forward on 
> these ones because they're useful and maybe someday we can introduce some 
> Jenkins-specific checks somewhere.
>
> One thing I do wish for (not limited to security issues): that
> SpotBugs could be asked to report a warning (or error?) if you have an
> annotation in the code which would _not_ be required in its current
> scanner configuration. Sometimes people just drop an annotation onto
> some 100-line method asking it to ignore an apparent NPE or
> synchronization mismatch or whatever, the code is subsequently
> refactored, and then no one ever thinks to go back and verify that the
> annotation is still necessary. IDEs and style checkers can flag unused
> imports or private methods; this would be in the same mold.
>
> +10
>
> This would be fantastic. Sometimes I remove a suppress annotation and see 
> if it's still necessary -- often it isn't. Going through these analyses I 
> found a number of cases where an existing annotation was no longer 
> necessary. It would be great to have this capability, but I'm not motivated 
> enough to contribute this to spotbugs.
>
> Jeff
>

We now have the ability to actually put the suppressions at a finer level 
than just the method for many issues.  If we started to consiously do that 
it would be clearer when some things can be removed.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/54b09ff3-0494-4e30-8b32-b50cf144e654%40googlegroups.com.

Re: Adopt a plugin request

[Baptiste Mathus]

Please also add existing/current maintainers in CC, we'll need either
her/his/their approvals, or wait 14 days usual timeout.
Cf. https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

On Fri, Dec 13, 2019 at 10:37 AM Terry Moreland 
wrote:

> I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
> using either of the following git accounts.
>
> 
> 
> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
> pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
> github id: either my work account (preferred): tmoreland-r7 or personal
> account: tsmoreland
> jenkins id: tmoreland
>
> inclusion of both accounts is because my personal account is associated
> with this e-mail address which could join the group while my work account
> is restricted from joining google groups
>
> In case it makes any difference the current maintainer's e-mail address is
> currently being redirected to my work account (terry_morel...@rapid7.com),
> I cannot gain control of his github account due as it's using two-factor
> authentication.  Nonico Bugash is no longer with Rapid7 which is why I'm
> seeking to become maintainer
>
> Terry Moreland
> terry.s.morel...@gmail.com
> terry_morel...@rapid7.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPyTVp0wiDYZX1vFtpXL21d4FUisv7BDi5M%2BbY7cAw3MMC_JKw%40mail.gmail.com.

Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Ivan Fernandez Calvo]

I'd like to be involved also at least on the testing part

El martes, 10 de diciembre de 2019, 12:34:05 (UTC+1), Oleg Nenashev 
escribió:
>
> BTW, I suggest the following list of maintainers based on the recent 
> activity:
>
>- Mark Waite
>- Alex Earl
>- Carlos Sanchez
>- Oleg Nenashev
>- Baptiste Mathus
>- Olivier Vernin
>
> Alternative is to just keep all members of 
> https://github.com/orgs/jenkinsci/teams/docker/members though some 
> contributors are not active at the moment
>
> BR, Oleg
>
> On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:
>>
>> I would like that very much
>>
>> On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev  wrote:
>>
>>> Hi all,
>>>
>>> Right now we have a number of official packages for Docker:
>>>
>>>- https://github.com/jenkinsci/docker  
>>>- https://github.com/jenkinsci/docker-slave  
>>>- https://github.com/jenkinsci/docker-ssh-slave 
>>>- https://github.com/jenkinsci/docker-jnlp-slave 
>>>- https://github.com/jenkinsci/jnlp-agents  
>>>
>>> All these repositories have different teams which define permissions/. 
>>> In addition to that we have jenkinsci/docker and 
>>> jenkinsci/docker-packaging-team team which also grant permissions. It is 
>>> quite difficult to manage the repositories in the current state, and it is 
>>> difficult to request reviews.
>>>
>>> I suggest to keep things simple and just proceed with a single team for 
>>> the official packaging:
>>>
>>>- Introduce an official "docker-packaging-team" under umbrella of 
>>>Platform Special Interest group which currently manages Docker packaging
>>>- Cleanup existing teams, leave just one for all official Jenkins 
>>>master and agent mages. Plugin Docker packaging (e.g. Remoting over 
>>> Apache 
>>>Kafka, Swarm plugin) will not be affected
>>>- Update GitHub and DockerHub teams to reflect the changes (mostly 
>>>jenkins4eval which grants write permissions)  
>>>- Add new team to CODEOWNERS in all repos
>>>
>>> WDYT?
>>>
>>> Thanks in advance,
>>> Oleg
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a2eb969d-f874-47a0-9fcc-51ed874f2128%40googlegroups.com.

Adopt a plugin request

[Terry Moreland]

I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
using either of the following git accounts.



jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
github:  https://github.com/rapid7/jenkinsci-appspider-plugin
pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
github id: either my work account (preferred): tmoreland-r7 or personal
account: tsmoreland
jenkins id: tmoreland

inclusion of both accounts is because my personal account is associated
with this e-mail address which could join the group while my work account
is restricted from joining google groups

In case it makes any difference the current maintainer's e-mail address is
currently being redirected to my work account (terry_morel...@rapid7.com),
I cannot gain control of his github account due as it's using two-factor
authentication.  Nonico Bugash is no longer with Rapid7 which is why I'm
seeking to become maintainer

Terry Moreland
terry.s.morel...@gmail.com
terry_morel...@rapid7.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%40mail.gmail.com.

Re: Proposal: New twitter contributors

[Harinder Singh]

Good going @Oleg Nenashev and @Mark Waite.

On Wednesday, 11 December 2019 22:05:28 UTC+5:30, Tracy Miranda wrote:
>
> Hi all,
>
> As per the process outlined in JEP 10 
> , I would like to 
> propose two new Twitter Contributors for the @jenkinsci account. 
>
> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via 
> the Advocacy gitter channel as well as tweeting community highlights around 
> hacktoberfest, gsoc, SIGs, elections etc. For example
> https://twitter.com/oleg_nenashev/status/1202631389277032449
> https://twitter.com/oleg_nenashev/status/1194982086521872384
> https://twitter.com/oleg_nenashev/status/1176981880786313217
>
> 2. Mark Waite - Mark regularly tweets around Platform SIG & Documentation 
> SIG, Jenkins git plugin, Jenkins online meetups and other community 
> highlights. For example:
> https://twitter.com/MarkEWaite/status/1190616140868808705  
> https://twitter.com/MarkEWaite/status/1180093593073045504
> https://twitter.com/MarkEWaite/status/1192437176446812160
>
> By giving Oleg & Mark access to schedule tweets, etc it will help the 
> community with more timely and regular communication around the many 
> community activities and technical developments.
>
> Please go ahead and vote/comment on this proposal. I will also add to an 
> upcoming board meeting for approval there. 
>
> Regards,
> Tracy 
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4ae15627-913c-4f98-932c-1499230186c3%40googlegroups.com.