Re: Proposal: Docker packaging changelogs

[slide]

I think the tags in dockerhub would remain tied to a version of Jenkins, 
meaning you could still do jenkins/jenkins:2.185-slim to get a Jenkins 
2.185 version. I think this is more for changelog info and releases on the 
github to "tag" the changes that are occurring in the scripts and infra to 
build the image. People would be able to see changes in ENV and ARG items 
and so forth that only relate to the docker images themselves. I am not 
sure how this would be notated in a tag on dockerhub, maybe that needs to 
be spelled out more in the proposal.

On Tuesday, July 23, 2019 at 4:26:32 PM UTC-7, Gavin Mogan wrote:
>
> Shouldn't there be a 1:1 or 1:many relationship between a Jenkins release 
> and docker release?
>
> Jenkins 2.150 should map to jenkinsci/Jenkins:2.150 docker image (I forgot 
> the docker url but should be similar)
>
> Maybe 2.150-1 if a docker specific fix need to go out?
>
> If so, wouldn't those changes be appropriate to tie to the same version in 
> the changelog? Maybe with a docker label/pill to say it's docker only.
>
> Gavin
>
> On Tue., Jul. 23, 2019, 2:38 p.m. Oleg Nenashev,  
> wrote:
>
>> Hi all,
>>
>> As many of Docker adopters know, we do not regularly put packaging 
>> changelogs to Jenkins release notes: https://jenkins.io/changelog/. 
>> Unless something goes really wrong, users have no practical way to know 
>> what has changed in Docker packaging, and they have to go to the commit 
>> history and somehow track down the commit used for their Jenkins version. 
>> It is a natural follow-up to the Continuous Delivery we use for Docker 
>> images, but is not convenient for many users. Docker packaging is a 
>> mission-critical deliverable for the Jenkins project, and I believe users 
>> deserve to see the changelogs tehere and to see cool features we deliver 
>> there (like recent official CentOS images).
>>
>> I would like to propose adding changelog for Docker releases. I have 2 
>> versioning options in mind:
>>
>> Option 1:
>>
>>- We introduce independent versioning for Docker packaging. This 
>>versioning follows the semver approach, and we start from 2.0.0 or any 
>>similar version which is explicitly different from Jenkins versioning
>>- Release versions are considered as experimental, delivery pipelines 
>>keep using latest versions and commit references as before
>>- If the experiment gets positive user feedback, we review options to 
>>align Docker packaging versions and Jenkins 
>>
>> Option 2:
>>
>>- We retrospectively follow Jenkins LTS versioning. Docker packaging 
>>version changelogs are released when we de-facto know what went to LTS  
>>- Such approach might be more convenient for LTS users, and we can 
>>lnk changelogs from Jenkins release notes
>>- If the approach is well accepted by users, we can again reconsider 
>>the implementation to make versions a part of the delivery pipeline
>>
>> I have submitted https://github.com/jenkinsci/docker/pull/856 which 
>> enables semver changelogs for Docker packaging. If the experiment is 
>> successful, we could do similar change in 
>> https://github.com/jenkinsci/packaging .
>>
>> I would appreciate feedback about the proposed options.
>>
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLD%3D0PDCEe96ERFSAmxk7Uinmy91_G7DaBgHymcT%3DphVRA%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/4cae2f5a-abbf-4044-a22f-7d35b4ee5c0c%40googlegroups.com.

Re: Proposal: Docker packaging changelogs

[Gavin]

Shouldn't there be a 1:1 or 1:many relationship between a Jenkins release
and docker release?

Jenkins 2.150 should map to jenkinsci/Jenkins:2.150 docker image (I forgot
the docker url but should be similar)

Maybe 2.150-1 if a docker specific fix need to go out?

If so, wouldn't those changes be appropriate to tie to the same version in
the changelog? Maybe with a docker label/pill to say it's docker only.

Gavin

On Tue., Jul. 23, 2019, 2:38 p.m. Oleg Nenashev, 
wrote:

> Hi all,
>
> As many of Docker adopters know, we do not regularly put packaging
> changelogs to Jenkins release notes: https://jenkins.io/changelog/.
> Unless something goes really wrong, users have no practical way to know
> what has changed in Docker packaging, and they have to go to the commit
> history and somehow track down the commit used for their Jenkins version.
> It is a natural follow-up to the Continuous Delivery we use for Docker
> images, but is not convenient for many users. Docker packaging is a
> mission-critical deliverable for the Jenkins project, and I believe users
> deserve to see the changelogs tehere and to see cool features we deliver
> there (like recent official CentOS images).
>
> I would like to propose adding changelog for Docker releases. I have 2
> versioning options in mind:
>
> Option 1:
>
>- We introduce independent versioning for Docker packaging. This
>versioning follows the semver approach, and we start from 2.0.0 or any
>similar version which is explicitly different from Jenkins versioning
>- Release versions are considered as experimental, delivery pipelines
>keep using latest versions and commit references as before
>- If the experiment gets positive user feedback, we review options to
>align Docker packaging versions and Jenkins
>
> Option 2:
>
>- We retrospectively follow Jenkins LTS versioning. Docker packaging
>version changelogs are released when we de-facto know what went to LTS
>- Such approach might be more convenient for LTS users, and we can lnk
>changelogs from Jenkins release notes
>- If the approach is well accepted by users, we can again reconsider
>the implementation to make versions a part of the delivery pipeline
>
> I have submitted https://github.com/jenkinsci/docker/pull/856 which
> enables semver changelogs for Docker packaging. If the experiment is
> successful, we could do similar change in
> https://github.com/jenkinsci/packaging .
>
> I would appreciate feedback about the proposed options.
>
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLD%3D0PDCEe96ERFSAmxk7Uinmy91_G7DaBgHymcT%3DphVRA%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/CAG%3D_DusscV_Ms6W5qZph%3DFXusO6wObbJvXee3WFgTTNWQcjwEQ%40mail.gmail.com.

Proposal: Docker packaging changelogs

[Oleg Nenashev]

Hi all,

As many of Docker adopters know, we do not regularly put packaging
changelogs to Jenkins release notes: https://jenkins.io/changelog/. Unless
something goes really wrong, users have no practical way to know what has
changed in Docker packaging, and they have to go to the commit history and
somehow track down the commit used for their Jenkins version. It is a
natural follow-up to the Continuous Delivery we use for Docker images, but
is not convenient for many users. Docker packaging is a mission-critical
deliverable for the Jenkins project, and I believe users deserve to see the
changelogs tehere and to see cool features we deliver there (like recent
official CentOS images).

I would like to propose adding changelog for Docker releases. I have 2
versioning options in mind:

Option 1:

   - We introduce independent versioning for Docker packaging. This
   versioning follows the semver approach, and we start from 2.0.0 or any
   similar version which is explicitly different from Jenkins versioning
   - Release versions are considered as experimental, delivery pipelines
   keep using latest versions and commit references as before
   - If the experiment gets positive user feedback, we review options to
   align Docker packaging versions and Jenkins

Option 2:

   - We retrospectively follow Jenkins LTS versioning. Docker packaging
   version changelogs are released when we de-facto know what went to LTS
   - Such approach might be more convenient for LTS users, and we can lnk
   changelogs from Jenkins release notes
   - If the approach is well accepted by users, we can again reconsider the
   implementation to make versions a part of the delivery pipeline

I have submitted https://github.com/jenkinsci/docker/pull/856 which enables
semver changelogs for Docker packaging. If the experiment is successful, we
could do similar change in https://github.com/jenkinsci/packaging .

I would appreciate feedback about the proposed options.

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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLD%3D0PDCEe96ERFSAmxk7Uinmy91_G7DaBgHymcT%3DphVRA%40mail.gmail.com.

GSoC/Outreachy 2019 mid-term demos on July 24 and 25, 3PM UTC

[Oleg Nenashev]

Hi all,

On July 24 and 25 we will have demos by summer students working on Jenkins.
During this session Google Summer of Code and Outreachy students will
present the results they achieved in their projects. This is a midterm
evaluation, all projects are in progress. But we have a lot to present. You
can find abstract of presentations here
.Tentative
agenda  is available below (subject to minor changes) :

July 24: https://www.youtube.com/watch?v=tnoObQqGhyM

   - Parichay Barpanda - Multibranch Pipeline support for GitLab SCM
   - Abhyudaya Sharma - Role Strategy performance improvements and a new
   Folder Authorization Plugin
   - Long Nguyen - Remoting over Apache Kafka. Docker/K8s Features

July 25: https://www.youtube.com/watch?v=HlENuZZq7zc

   - Natasha Stopa - Plugin Installation Manager CLI Tool / Library
   - Nancy Chauhan - Jenkins Pipelines for OpenRISC (LibreCores CI)
   - Aarthi Rajaraman, Gayathri Rajendar - Audit Log Plugin
   - Jack Shen - Working Hours Plugin - UI Improvements

Gitter channel for Q: https://gitter.im/jenkinsci/gsoc-sig
.
If you want to join the sessions, participant link will be posted there 10
minutes before the meeting.

Best regards,
Oleg Nenashev
GSoC Org Admin

-- 
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/CAPfivLCS1g0C1n9c61%2BB5VHFAi2kW8KPeBLpVpxRXZvMS9pLyA%40mail.gmail.com.

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

[Oleg Nenashev]

With Dependabot acquisition by GitHub, the project got some development 
boost.
Unfortunately, there is still no support of org-wide configurations, so we 
cannot just put defaults to https://github.com/jenkinsci/.github 
But we could at least put some samples there.

I would also like to enable Dependabot for Jenkins Test Harness if nobody 
is against.

Once Jesse finishes his work on https://github.com/jenkinsci/bom/ , it 
would be great to combine Dependabot and plugins with BOM (especially for 
Pipeline which is nightmare to handle in Dependabot).

BR, Oleg


On Monday, June 10, 2019 at 7:04:08 PM UTC+2, Oleg Nenashev wrote:
>
> done!
>
> On Mon, Jun 10, 2019 at 6:40 PM Basil Crow  wrote:
>
>> On Wednesday, May 22, 2019 at 11:47:09 PM UTC-7, Oleg Nenashev wrote:
>>>
>>> I am fine with going forward with enabling Dependabot for a wider set of 
>>> plugins.
>>>
>>
>>  Can you please add the following repositories:
>>
>> https://github.com/jenkinsci/swarm-plugin
>> https://github.com/jenkinsci/text-finder-plugin
>>
>> Thanks,
>> Basil
>>
>> -- 
>> 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/XMllKuWLO_8/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/e15d83eb-6fe5-4c80-99a5-d124fbd19134%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/5a7200ee-972c-4340-a2a8-77ec9c116eb1%40googlegroups.com.

[EVENT] DevOps World Jenkins World SF - Full agenda is live

[Alyssa Tong]

Hi All,

Just a reminder this event is happening in a few weeks, Aug 12 - 15, 2019,
in San Francisco. CDF will be taking part in the conference as well. Below
are some important links, join us!

   - The contributor summit 
   - Full agenda is HERE
   
   - Check out our posts  for the Jenkins
   activities and who will be at the event
   - CDF track - will be posted on the main agenda soon
   - Use code *PREVIEW* for $799 registration
   

See you there!
alyssa

-- 
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/CAC9wNaxxOcXz-dgBu9%3DCvTWTY4e88QDbBD5%3DmS%2B1Tn0U7WajuQ%40mail.gmail.com.

Re: Remote agent test not running on my local Windows developer machine

['Robin Jansohn' via Jenkins Developers]

OK, now I understand it. It's expecting to reach a real server under 
example.com and that didn't work because my proxy wasn't used and refused 
the connection. That test case really isn't a good idea... I'll need to 
figure something out how to test this in a more portable way...

-- 
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/dd86bb22-8cc7-440b-ad99-1adccf46e231%40googlegroups.com.

Re: Remote agent test not running on my local Windows developer machine

['Robin Jansohn' via Jenkins Developers]

Thanks for having a look. I added the BuildWatcher and also changed the URL 
to "http://localhost; but it doesn't change anything in the result. 
Comparing the stacktraces I can see that in my case the exception is 
already thrown in "org.codehaus.cargo.container.
tomcat.internal.TomcatManager.invoke(TomcatManager.java:567)" calling 
"connection.connect();" while your linux build goes further and correctly 
throws the expected exception when reading the response calling "response = 
toString(connection.getInputStream(), MANAGER_CHARSET);".

So the question remains what could cause my system to throw a connection 
refused while others don't...


On Tuesday, 23 July 2019 16:20:31 UTC+2, Jesse Glick wrote:
>
> I filed https://github.com/jenkinsci/deploy-plugin/pull/38 with some 
> hints. 
>

-- 
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/8b3c5cbd-396b-4e7b-82ba-3971f0e7c27c%40googlegroups.com.

Re: Remote agent test not running on my local Windows developer machine

[Jesse Glick]

I filed https://github.com/jenkinsci/deploy-plugin/pull/38 with some hints.

-- 
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/CANfRfr3cYu6Nn%3DeoEQM_-xQznCW0T26jAT-F%3D736SY4ot-jdBg%40mail.gmail.com.

Requesting Maintenance access for Instant Messaging and IRC bot plugins (or just as well, calling for some active maintainer to step up)

[Jim Klimov]

Hello all,

   I would like to ask for the merge rights on 
https://github.com/jenkinsci/instant-messaging-plugin/ and 
https://github.com/jenkinsci/ircbot-plugin as others and myself have done a 
number of PRs for them (community reviews would also be very welcome!) with 
improvements that work for us locally - but at a risk of discrepancy 
when/if the upstream plugins march on without these changes, and also the 
user community at large does not yet benefit from the working solutions 
(and we don't benefit from someone discovering glaring bugs and omissions 
;) ).

   Just as well, if anyone more qualified with Java (I am not confident 
reviewing other people's PRs in matters that I don't understand well) and 
with more time available than myself would step up to *really *maintain 
these plugins and review code submissions, I'm all for it. As before, my 
github and Jenkins LDAP and Jenkins JIRA accounts are all "jimklimov".

   Aside from some of my improvements to make the IRCbot interface for 
build monitoring and management a bit better, there is the pipeline 
integration for instant messaging (IRC works for us, there is also a stale 
Jabber PR at https://github.com/jenkinsci/jabber-plugin/pull/18 that got 
out of sync - I used its codebase for IRC so can say the logic works, but 
we don't have a server to test or use the solution against).

   The currently assigned instant-messaging and ircbot plugin maintainer 
Christoph Kutzinski @kutzi signed off in 
https://github.com/jenkinsci/ircbot-plugin/pull/21 suggesting to ask here 
on the list:

>  I'm still listed as maintainer for this plugin, but I'm not really 
acting anymore - sorry.
 As I'm not part of the jenkins-dev mailing list anymore, I cannot even ask 
to remove me as maintainer from the wiki page ... That being said: I think 
you'll have the best chances if you ask on the jenkins-dev mailing list for 
support. Maybe someone else wants to step up as the maintainer? Maybe you 
want to?

   Of other recent committers/releasers, Oliver Gondža wrote he is not a 
maintainer but just technically made latest releases of these plugins, and 
I do not have information about disposition of Drew DeVault (CCed) except 
that there were no replies on ircbot PRs open for many weeks now ;)

   The Jabber plugin mentioned above is, I believe, actively maintained by 
@Flowdalic (also CCed for completeness).

Thanks for listening,
Jim Klimov


PS: This is a re-post of a message I tried to send from another account, so 
there I CC'ed
  Drew DeVault , Florian Schmaus 
by addresses I found from their GitHub accounts.

-- 
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/38ca5bed-3ec1-4191-92c8-331bfd7dfa8d%40googlegroups.com.

Remote agent test not running on my local Windows developer machine

['Robin Jansohn' via Jenkins Developers]

I'm trying to build the deploy-plugin project on my local Windows 10 
developer machine but one of the tests is failing and I fail to see what is 
missing. The build on the Jenkins CI is working, e.g. 
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fdeploy-plugin/detail/master/9/pipeline

It's going to be difficult to release a new version if it's not running on 
my local machine. Any help appreciated!


> mvn -Dtest=RemoteCallableTest#testCallableSerialization test
[...]
[INFO] --- maven-enforcer-plugin:1.4.1:display-info (display-info) @ deploy 
---
[INFO] Maven Version: 3.5.0
[INFO] JDK Version: 1.8.0_181 normalized as: 1.8.0-181
[INFO] OS Info: Arch: amd64 Family: dos Name: windows 10 Version: 10.0
[...]
=== Starting 
testCallableSerialization(hudson.plugins.deploy.RemoteCallableTest)
Jul 23, 2019 11:20:44 AM hudson.slaves.CommandLauncher launch
INFO: slave agent launched for slave0
Jul 23, 2019 11:20:44 AM hudson.Util warnWindowsSymlink
WARNING: Symbolic links enabled on this platform but disabled for this 
user; run as administrator or use Local Security Policy > Security Settings 
> Local Policies > User Rights Assignment > Create symbolic links
Jul 23, 2019 11:20:46 AM hudson.model.Run execute
INFO: test0 #1 main build action completed: SUCCESS
Jul 23, 2019 11:20:48 AM hudson.model.Run execute
INFO: test0 #2 main build action completed: SUCCESS
WARN: The method class 
org.apache.commons.logging.impl.SLF4JLogFactory#release() was invoked.
WARN: Please see http://www.slf4j.org/codes.html#release for an explanation.
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
80.821 s <<< FAILURE! - in hudson.plugins.deploy.RemoteCallableTest
[ERROR] 
testCallableSerialization(hudson.plugins.deploy.RemoteCallableTest)  Time 
elapsed: 79.886 s  <<< FAILURE!
java.lang.AssertionError:

Expected: a string containing "java.io.FileNotFoundException: 
http://example.com/manager/text/list;
 but: was "Legacy code started this job.  No cause information is 
available
Building remotely on slave0 in workspace 
C:\Users\xyz\AppData\Local\Temp\jenkinsTests.tmp\jenkins3814923641781041047test\workspace\test0
[DeployPublisher][INFO] Attempting to deploy 1 war file(s)
[DeployPublisher][INFO] Deploying 
C:\Users\xyz\AppData\Local\Temp\jenkinsTests.tmp\jenkins3814923641781041047test\workspace\test0\simple5015252018370588681.war
 
to container Tomcat 8.x Remote with context
ERROR: Build step failed with exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy 
[C:\Users\xyz\AppData\Local\Temp\jenkinsTests.tmp\jenkins3814923641781041047test\workspace\test0\simple5015252018370588681.war]
at 
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:188)
at 
hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:81)
at 
hudson.plugins.deploy.CargoContainerAdapter$DeployCallable.invoke(CargoContainerAdapter.java:167)
at 
hudson.plugins.deploy.CargoContainerAdapter$DeployCallable.invoke(CargoContainerAdapter.java:1)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2719)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at ..remote call to slave0(Native Method)
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at hudson.FilePath.act(FilePath.java:979)
at hudson.FilePath.act(FilePath.java:968)
at 
hudson.plugins.deploy.CargoContainerAdapter.redeployFile(CargoContainerAdapter.java:133)
at 
hudson.plugins.deploy.PasswordProtectedAdapterCargo.redeployFile(PasswordProtectedAdapterCargo.java:95)
at 
hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:113)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668)
at 

Re: Governance Meeting Agenda items related to GSoC - July 31, 2019 meeting

[Oleg Nenashev]

>
> The shipping of tshirts and stickers is estimated at $1220 USD (if all 64 
> offers are accepted).
>

This is with assumption that  nobody picks up the swag at DW-JW.
I believe that the final cost would be lower.


On Tuesday, July 23, 2019 at 3:07:02 AM UTC+2, martinda wrote:
>
> Hello everyone.
>
> I have three three topics for the next governance meeting on July 31, 
> 2019. Unfortunately due to a conflict I will not be able to attend in 
> person. I will try to find another GSoC Org Admin to represent me for these 
> requests.
>
> 1) Earmarking and collecting JWDW 2019 swag for shipping to GSoC 
> Participants
>
> Is it possible to you earmark 64 T-shirts and 256 stickers for Google 
> Summer of Code participants from years 2018 and 2019? I would like to pick 
> up the swag at Jenkins World in San Francisco next month, take it home and 
> ship it to GSoC 2018 and 2019 participants. We don't have t-shirt sizes yet 
> but we will be collecting that info soon.
>
> These numbers represent the absolute maximum, I expect we will need less 
> than that once we collect all the shipping addresses. Some will not 
> respond, some will pick up the swag in person at the conference. I will 
> have the exact number by August 8, 2019.
>
> Let me know if that is possible. We plan to start shipping after JWDW, in 
> late August.
>
> 2) Budget Approval Request for shipping swag
> The shipping of tshirts and stickers is estimated at $1220 USD (if all 64 
> offers are accepted).
> Shipping will be via regular surface mail. Triple the cost for faster 
> delivery.
>
> 3) Budget Approval for Poster at Community or Contributor booth:
> I created a poster to display at the JWDW 2019 conference in SF. I will 
> bring the poster with me, then I can leave it to someone who can take it to 
> Lisbon later.
> The poster is here: 
> https://github.com/martinda/jenkins-gsoc-gsod-outreachy-poster/blob/master/poster.svg
>
> Printing cost and carrying tube: $100 USD
>
>
> Best Regards,
> Martin d'Anjou
> Jenkins GSoC Org Admin Team
>

-- 
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/48eac22d-ebe8-44da-a7fb-6b5668be8665%40googlegroups.com.