Re: @QueryParameter in form validation is not filled for dropdownDescriptorSelector

[Jesse Glick]

On Thu, Feb 14, 2019 at 5:55 PM Ullrich Hafner  wrote:
> I think there still I a bug in Stapler here

Does look that way. Please file it, and of course if you can track
down the cause a PR would be great.

The only thing unusual I see about your example is the use of `int`,
where most check methods would be accepting `String`s.

-- 
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/CANfRfr3G_KpFqw%2Bz_B6TtkDGT%2BKHLaCJ%3D_dWSDAdQj06XwRxFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: @QueryParameter in form validation is not filled for dropdownDescriptorSelector

[Ullrich Hafner]

I finally managed it to get it fixed (at least in my plugin). I think there 
still I a bug in Stapler here:

If I define the validation method using:
public FormValidation doCheckHighThreshold(@QueryParameter final int 
highThreshold,
@QueryParameter final int normalThreshold) {
return VALIDATION.validateHigh(highThreshold, normalThreshold);
}
then in the generated HTML the attribute checkdependson is empty:



If I rather use
public FormValidation doCheckHighThreshold(@QueryParameter(value = 
"highThreshold") final int highThreshold,
@QueryParameter(value = "normalThreshold") final int normalThreshold) {
return VALIDATION.validateHigh(highThreshold, normalThreshold);
}
Then in the generated HTML the attribute checkdependson is correct:



>From the documentation of @QueryParameter: if value is not given, then the 
>name of the parameter should be used.

> Am 23.03.2018 um 15:25 schrieb Jesse Glick :
> 
> On Thu, Mar 22, 2018 at 7:05 PM, Ullrich Hafner
>  wrote:
>> I created an issue: JENKINS-50355.
> 
> Most likely some typo or other bug in your plugin code, but hard to
> know offhand. If there a simple way to reproduce this problem locally,
> state that in the issue.
> 
>> Maybe the problem is that the views are in different plugins and are loaded 
>> by different class loaders...
> 
> Should not matter.
> 
> --
> 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/CANfRfr3cDq%3D3_Jjzt%3DJRcsbmdZ4wja75qY%2BqFzRJ314Z4cMhRg%40mail.gmail.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/7E4CC619-5913-4D52-A7F7-4D82C93E1A23%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Packing extra files along with depedency jars in hpi

[Baptiste Mathus]

Definitely sounds like a maven-remote-resources-plugin use case.
Used this in the past to share versioned pmd rulesets IIRC, worked like a
charm.

Le mar. 12 févr. 2019 à 20:40, Rajeev Ranjan  a
écrit :

> Hi team,
> There's a issue which is bugging me a lot from a while. Don't know if it
> has been asked before.
> I am working on one plugin where I need some powershell files to execute
> some commands, and is shared across some different projects. These files
> are placed in public respository in a remote location. *Is it possible to
> get these files at build time and package these extra files in the hpi,
> along with dependency jars* which is created? If yes, how?
> Note: files are not in java project, so can't add as project depenenct
> itself.
> Thanks in advance
>
> --
> 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/ed8012c9-12f3-43c7-a442-df8b89437ac9%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/CANWgJS7YU6V9NSP7nYJcxYP15999QQ_mP2H_B%2BARbx%2BRwSMhmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Access to github for ease-plugin for 2 new developers

[Slide]

It should be done now. They should have invitations to the org that they
will need to accept.

On Thu, Feb 14, 2019 at 2:32 PM Robert Friedman  wrote:

> They are jrodgut-sg and fin7710. Thanks!
>
> On Thursday, February 14, 2019 at 4:22:51 PM UTC-5, slide wrote:
>>
>> What are their GitHub usernames?
>>
>> On Thu, Feb 14, 2019, 14:09 Robert Friedman >
>>> Help here would be appreciated, it is still unresolved. Thanks!
>>>
>>>
>>> On Wednesday, January 30, 2019 at 3:33:13 PM UTC-5, Robert Friedman
>>> wrote:

 I need some help with getting new maintainers added to
 https://github.com/jenkinsci/ease-plugin so that they have commit
 access. They were added to the permissions repo in this commit:
 https://github.com/jenkins-infra/repository-permissions-updater/pull/933,
 but they never received invitations to the git repo itself. Can you please
 assist? Apologies if I missed a step in the process. Thanks!


 --
>>> 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-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/ae18a6b5-9429-47d0-89b3-fd09b460dff8%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/0d0c707a-ca91-42f8-a504-32b6c73e9212%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Website: http://earl-of-code.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/CAPiUgVdNzXumMc_KU0r4VptnfgrvOxi%2BvFmfHKJh-sJzqmj5MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Access to github for ease-plugin for 2 new developers

[Robert Friedman]

They are jrodgut-sg and fin7710. Thanks!

On Thursday, February 14, 2019 at 4:22:51 PM UTC-5, slide wrote:
>
> What are their GitHub usernames? 
>
> On Thu, Feb 14, 2019, 14:09 Robert Friedman   wrote:
>
>> Help here would be appreciated, it is still unresolved. Thanks!
>>
>>
>> On Wednesday, January 30, 2019 at 3:33:13 PM UTC-5, Robert Friedman wrote:
>>>
>>> I need some help with getting new maintainers added to 
>>> https://github.com/jenkinsci/ease-plugin so that they have commit 
>>> access. They were added to the permissions repo in this commit: 
>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/933, 
>>> but they never received invitations to the git repo itself. Can you please 
>>> assist? Apologies if I missed a step in the process. Thanks!
>>>
>>>
>>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/ae18a6b5-9429-47d0-89b3-fd09b460dff8%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/0d0c707a-ca91-42f8-a504-32b6c73e9212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Access to github for ease-plugin for 2 new developers

[Slide]

What are their GitHub usernames?

On Thu, Feb 14, 2019, 14:09 Robert Friedman  Help here would be appreciated, it is still unresolved. Thanks!
>
>
> On Wednesday, January 30, 2019 at 3:33:13 PM UTC-5, Robert Friedman wrote:
>>
>> I need some help with getting new maintainers added to
>> https://github.com/jenkinsci/ease-plugin so that they have commit
>> access. They were added to the permissions repo in this commit:
>> https://github.com/jenkins-infra/repository-permissions-updater/pull/933,
>> but they never received invitations to the git repo itself. Can you please
>> assist? Apologies if I missed a step in the process. Thanks!
>>
>>
>> --
> 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/ae18a6b5-9429-47d0-89b3-fd09b460dff8%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/CAPiUgVdzvoHY9zE8%3DoRT0PxcyRPE%3DxXXuCauC-Y2%2BAYyaXR%2BOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Access to github for ease-plugin for 2 new developers

[Robert Friedman]

Help here would be appreciated, it is still unresolved. Thanks!


On Wednesday, January 30, 2019 at 3:33:13 PM UTC-5, Robert Friedman wrote:
>
> I need some help with getting new maintainers added to 
> https://github.com/jenkinsci/ease-plugin so that they have commit access. 
> They were added to the permissions repo in this commit: 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/933, 
> but they never received invitations to the git repo itself. Can you please 
> assist? Apologies if I missed a step in the process. Thanks!
>
>
>

-- 
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/ae18a6b5-9429-47d0-89b3-fd09b460dff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.164.1 started

[Oliver Gondža]

On 14/02/2019 16.38, Daniel Beck wrote:




On 14. Feb 2019, at 11:03, Oliver Gondža  wrote:

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146


Could you update this filter to include 'Fixed but Unreleased'? We're not 
consistently keeping the statuses up to date after a weekly release, and while 
we should fix that, we should make the back porting process more robust.

JENKINS-55197 is an example of such an invisible (former) 'lts-candidate' issue.



Good point, changed the relevant predicate to `statusCategory = Done`.

--
oliver

--
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/29c8e3d9-5c2d-e756-f2a1-c52cd7c8d5a7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GlobalConfiguration.all() throws IllegalStateException

[Carles Capdevila Tejada]

Getting the configuration at the StepExecution fixed it, thanks a lot for 
the help and the revelations!

El lunes, 4 de febrero de 2019, 15:21:28 (UTC+1), Jesse Glick escribió:
>
> On Mon, Feb 4, 2019 at 4:49 AM Carles Capdevila Tejada 
> > wrote: 
> > I thought that pipeline code is always executed in the master 
>
> “Pipeline code” is too broad an expression to be meaningful. The 
> bodies of specific API methods, such as `StepExecution.start` or 
> `SimpleBuildStep.perform`, are indeed run on the master. But if you 
> use `Callable` / `FileCallable` then you are requesting the body to 
> potentially be run on an agent. And `ConsoleLogFilter`s / 
> `TaskListenerDecorator`s may be run on agents. 
>
> > unless inside of a node() step 
>
> Running “inside” a `node` block has no effect on where code runs, 
> except insofar as code which _might_ run on an agent _could not_ even 
> start if you were not inside a `node` block. (Typically seen by the 
> engine refusing to run a step, throwing 
> `MissingContextVariableException`.) The `node` block merely offers a 
> contextual `FilePath`, `Computer`, etc. for any code which might ask 
> for it via `StepContext.get`. 
>
> > In the mentioned execution the step is called outside of a node() step, 
> like so: 
> > 
> > logFileFilter () { 
> > node (nodeLabel) { 
> >  ... 
> > 
> > So shouldn't it be executed on the master? 
>
> No, because the `sh` step inside `node` remotes a `TaskListener` to an 
> agent whose serial state includes your `ConsoleLogFilter`. 
>

-- 
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/99e4dff7-5cc0-4f17-b407-580b7f8fa645%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.164.1 started

[Daniel Beck]

> On 14. Feb 2019, at 11:03, Oliver Gondža  wrote:
> 
> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146

Could you update this filter to include 'Fixed but Unreleased'? We're not 
consistently keeping the statuses up to date after a weekly release, and while 
we should fix that, we should make the back porting process more robust.

JENKINS-55197 is an example of such an invisible (former) 'lts-candidate' issue.

-- 
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/80719A72-B718-47D4-9F25-8D6B5D20CD87%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Setup external Jenkins processes to test via JCasC

[Jesse Glick]

On Thu, Feb 14, 2019 at 6:34 AM Oliver Gondža  wrote:
> Does it sound useful to you?

Yes!

My main feedback is that, if possible, this should be reworked to use
a Docker container to launch Jenkins, with the image configurable on a
per-test basis. (That does not preclude mounting Maven-specific files
like `jenkins.war` and dependency `*.jpi` from the local repository or
`target` directory.) This would allow for much better control over
tests. I have sorely missed this in `mercurial-plugin`, for example.
There probably also needs to be some work done to allow agents to also
run in containers, like `docker-fixtures` does, with ports bound.
(Docker Compose? Minikube / microk8s? Something based on
testcontainers.org?)

I suggest you assign

https://issues.jenkins-ci.org/browse/JENKINS-41827

to yourself, as you seem to be implementing something very much like
what this wished for.

-- 
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/CANfRfr2S85Vgx7N%3D7DTM3qkOBqAqBDr7M4zK9RTs6cZ%2B2NZuFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: 2 weeks comment period for moving to the CDF

[R. Tyler Croy]

(replies inline)

On Mon, 11 Feb 2019, Kohsuke Kawaguchi wrote:

> This is the formal call for input for the decision to move the Jenkins
> project to the newly forming Continuous Delivery Foundation. (I was told
> that my earlier attempt
>  to
> just change the subject didn't create a wholly new thread, hence this email)


Thanks for splitting this out into a new thread, just to make sure people have
the opportunity to see it.


I'm personally excited for this move, so if I am unable to attend the meeting
next week due to work getting in the way, consider this my emphatic +1 in
support of Jenkins moving to the CDF!




Cheers


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
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/20190214143004.GO23906%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.

Setup external Jenkins processes to test via JCasC

[Oliver Gondža]

The other day, I have spent a week on crafting a reusable JUnit rule to 
complement JenkinsConfiguredWithCodeRule[2] that create Jenkins SUTs as 
independent local processes. The use case here is starting Jenkins with 
realistic classloading environment, testing realistic start/stop/restart 
scenarios (otherwise affected by JUT) or setting up multiple Jenkinses 
for test. I am distributing this to see if folks are interested in 
having something like this available so we can extract it from the 
plugin this was initially developed for.


---

The simplest way to consume it is:

```
public @Rule TemporaryFolder tmp = new TemporaryFolder();
public @Rule ExternalJenkinsRule ejr = new ExternalJenkinsRule(tmp);

@Test
@ExternalFixture(name = "my-jenkins", resource = "my-jenkins.yaml", 
injectPlugins = "matrix-auth")

public void myJenkins() throws Exception {
ExternalJenkinsRule.Fixture myJenkins = ejr.fixture("my-jenkins");
com.offbytwo.jenkins.JenkinsServer jenkinsServer = 
myJenkins.getClient();

...
}
```

- The Jenkinses are launched in parallel in case there are multiple of them.
- Injected plugins are inject with their dependencies resolved by 
maven-hpi-plugin:resolve-test-dependencies (IOW, they have to be 
declared as maven dependencies but their injections is safe and fast).
- Primary means of controlling such Jenkins is through 
jenkinsci/java-client-api.

- Dedicated temporary folder is allocated for every Jenkins.
- Jenkins log can be accessed for investigation.

For advanced usage one can subclass the ExternalJenkinsRule (as 
demonstrated by [1]) in order to:


- Rearrange or modify the declared fixture annotations per test (DRY).
- Alter plugins to inject (DRY).
- Specify particular environment variables, JVM or Jenkins arguments.
- All of the above can be tailored based on declared fixture role. 
Meaning the customizations deployed to individual fixtures do not have 
to be the same - common for heterogeneous grids.


There are certainly many areas to improve this, though for now my 
question is: Does it sound useful to you?


[1] https://github.com/jenkinsci/node-sharing-plugin/pull/106
[2] 
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/plugin/src/test/java/io/jenkins/plugins/casc/misc/JenkinsConfiguredWithCodeRule.java


Cheers
--
oliver

--
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/1be57933-62d2-7588-3e9e-83a4c7269b5d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Missing permission for the github repository

[Ullrich Hafner]

I’m also using travis for my plugin builds (additionally to ci.jenkins.io 
) :-)

It is much faster and sends mails if there are some failures. Also there is an 
out of box integration of some external tools (codacy, codecov, etc.).

> Am 14.02.2019 um 00:57 schrieb Gavin Mogan :
> 
> Out of curiosity, what are you trying to do on travis that you can't do with 
> public jenkins install?
> 
> https://ci.jenkins.io/job/Plugins/job/sidebar-link-plugin/job/master/ 
> 
> 
> https://ci.jenkins.io/job/Plugins/job/sidebar-link-plugin/job/master/badge/ 
>  
> has the badges
> 
> On Wed, Feb 13, 2019 at 6:44 AM  > wrote:
> As I understand that from your perspective it's better to control issues on 
> JIRA than Github but based on my experience users report issues much faster 
> and more often via Github. I'm going to monitor what is going on on JIRA as I 
> understand adopting also means be default assignee for JIRA component which 
> is fine.
> 
> Second fact which I have noticed recently is that without having proper 
> permission I was not able to integrate Travis CI with Github because Travis 
> checks if I have permission to the project. Following toggle was not present 
> for the one plugin but was for the second:
> 
> 
> 
> 
> 
> @Daniel - thanks, now looks good to me!
> 
> 
> 
> Damian
> 
> 
> --
> 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/7b8c5123-c3b4-4b78-9331-e496bee959ef%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/CAAgr96%2BpbqEQucJEiJvBpAitOhmhpU-YbSn8mAGKDrJGShz4RA%40mail.gmail.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/EAAA736C-55E5-4DC9-855B-01AC21D9E689%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Backporting for LTS 2.164.1 started

[Oliver Gondža]

Backporting has started and the RC is scheduled for 2019-02-27.

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
Fixed: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.164.1-fixed
Rejected: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.164.1-rejected

--
oliver

--
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/fed3de0b-17db-4983-f3c8-d1b3556f1ed7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: 2 weeks comment period for moving to the CDF

[Rick]

Thanks for your explanation. It's helpful to me.


On Thu, Feb 14, 2019 at 4:19 AM Kohsuke Kawaguchi  wrote:

> Thanks for the question, Rick.
>
> There will be Jenkins level things and CDF level things.
>
> The SIGs that we currently have are Jenkins level entities. In the short
> term all of them will remain as is. Over time, I think it makes a lot of
> sense that some SIGs be formed at the CDF level --- for example, advocacy
> of Continuous Delivery is one project I'd love to see move forward, and it
> makes a lot more sense to do that at the CDF level than at the Jenkins
> level. When/if CDF-level SIG happens, it's conceivable that some
> Jenkins-level SIGs be morphed into CDF-level SIG.
>
> The CDF charter outlines committees that are defined at the CDF level.
> More/less might get created over time by the decision of the CDF GB.
>
> The same thing with Ambassador. For the short term Jenkins-level
> ambassador will remain, but I think it also makes sense that the
> ambassadors be uplifted to the CDF level thing, especially if that makes
> this program bigger and better resourced. If after a discussion this is
> determined to be the case, then I think that's what's going to happen.
>
> Ultimately, my understanding is that it's really up to people who are
> interested in driving things forward to evolve the structure, like how
> we've been doing it in this project for the past decade. For the most part,
> it's not like those structures are cast in stone by the current charter.
> It's a living evolving document that we shape, and what we have right now
> is "just" a starting point.
>
> Does that help?
>
> 2019年2月12日(火) 17:28 Rick :
>
>> Hi KK,
>>
>> Thanks for giving more details about the CDF. This is all good from my
>> perspective. Just one question I want to ask.
>>
>> I know the main structure will remain. But how the relationship is going
>> between SIG and Committee? Another similar question is about the
>> ambassador. The CDF and Jenkins will both have the ambassador or just one
>> of them.
>>
>> Best regards,
>> Rick
>>
>> On Tue, Feb 12, 2019 at 12:35 AM Kohsuke Kawaguchi 
>> wrote:
>>
>>> This is the formal call for input for the decision to move the Jenkins
>>> project to the newly forming Continuous Delivery Foundation. (I was told
>>> that my earlier attempt
>>> 
>>> to just change the subject didn't create a wholly new thread, hence this
>>> email)
>>>
>>> Speaking as the board, if we are to pull the trigger and formalize this
>>> new home, given the magnitude of the proposal, we need to make a binding
>>> decision and record it as such. Given that this seems to be a topic that
>>> relatively small number of people care about, and that those reactions so
>>> far have been overwhelmingly positive, the board would like to set 2 weeks
>>> comment period ending on Feb 22nd, where we solicit anyone's organized
>>> thoughts on why you think we should or shouldn't move the Jenkins project
>>> under the proposed CDF. You can write it here, or if need be, send the
>>> board a private email at jenkinsci-bo...@googlegroups.com. We'll
>>> consider and respond to them, and provided that there still remains a
>>> significant consensus (like the one that we are seeing so far), then the
>>> board will make the binding decision.
>>>
>>> Not much of the existing structure of the Jenkins project will change.
>>> Committers, contributors, officers, teams, the board, and all that will
>>> still remain (including all the "normalization" work like voting.) The idea
>>> is that the board and officers of the Jenkins project will be the
>>> "oversight body of each TOC Project" (charter 7-b-i) and this links the
>>> chain of authority of the CDF and the Jenkins project. Our existing
>>> technical decision making process of JEP, SIG, PR, etc remain under our
>>> control. The whole of the draft charter can be seen here
>>> .
>>> Again, if anyone has questions, concerns, and/or opinions, I'd love to hear
>>> those.
>>>
>>> Please keep the discussion going. Organized thoughts are always better,
>>> but if you just want to pile on your +1, that'd be appreciated, too :-)
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>>> --
>>> 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/CAN4CQ4z7Q9jXL4PqfqVbBvmjsNy5B6uzEP%2BgnMFu0%2BnGQ6sLXw%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>>