Re: Bug Triage "Team"

I also would love if we cleared out the assignee setting entirely. There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue. I'd rather use assignee to track actually picking up the issue. Status to track triage state. Esp in credentials (which I

Re: Jobs creation on jenkins.ci.cloudbees.com restored

Yes I saw few duplicated stuffs but for now I don't see with the current code how to easily deactivate je job if it already on jenkins.io. I'll do it manually later today. For now we don't have a lot of exceptions thus it won't be too painful. Also we don't deploy snapshots of these builds (AFAIR)

Regarding issue WEBSITE-270 [Newcomer to Jenkins]

Hi, I'm new to Jenkins dev and I'd like some support at least till I solve a couple of issues so that I get acquainted with Jenkins way of contribution :) I'd like to know how to find the source code and build it. I have noticed that the source code is on github, but different issues will be

Re: Maintainer request Gitlab Plugin

I will add you as a committer ASAP. Given that we now have a couple of people jointly maintaining the plugin, I suggest that we limit the use of direct commits to updating documentation. For code changes, please continue to use PRs, so we can have some code review. Thanks and welcome aboard! On

Re: Bug Triage "Team"

On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner wrote: > I think this is not the common practice. Wouldn’t it be better to use the > in progress transition for such issues? > > When I create an issue and see that there is no assignee it gives me the > feeling that I

Re: Jobs creation on jenkins.ci.cloudbees.com restored

I just disabled https://jenkins.ci.cloudbees.com/job/plugins/job/pipeline-model-definition-plugin/ 'cos I just want the multibranch setup on ci.jenkins.io to run - is there a better way to ensure that a given plugin repo won't get built on jenkins.ci.cloudbees.com? A. On Thu, Jan 19, 2017 at

Jobs creation on jenkins.ci.cloudbees.com restored

Hi all, FYI with KK we fixed the automated creation of jobs for plugins (built with maven) on https://jenkins.ci.cloudbees.com/job/plugins/ ref: https://issues.jenkins-ci.org/browse/INFRA-954 The job is here :

Re: Bug Triage "Team"

I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues? When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in

Re: Bug Triage "Team"

2017-01-19 21:31 GMT+01:00 Mark Waite : > > > On Thu, Jan 19, 2017 at 12:51 PM Slide wrote: > >> If that is a common practice, then we can skip setting the assignee and >> focus on component assignment and reproducibility, or we can have a >>

Re: Bug Triage "Team"

On Thu, Jan 19, 2017 at 12:51 PM Slide wrote: > If that is a common practice, then we can skip setting the assignee and > focus on component assignment and reproducibility, or we can have a > "whitelist" of plugins that we set assignee for. The goal isn't to make > things

Re: Bug Triage "Team"

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things

Re: Bug Triage "Team"

On Thu, Jan 19, 2017 at 12:34 PM, Slide wrote: > The outcome of a triage on a specific issue would be that the correct > component(s) and assignee were there. Do we really need to set an assignee? For example for most `{workflow,pipeline}-*-plugin` components there is

Re: Bug Triage "Team"

This sounds like a solid first pass to me, worth trying out for a month or so to see how it goes. I'm also interested in helping, so put me on the list! On Jan 19, 2017 9:34 AM, "Slide" wrote: > There was a discussion in the Governance Meeting yesterday [1] about >

Bug Triage "Team"

There was a discussion in the Governance Meeting yesterday [1] about creating a Bug Triage "Team." The goal of this team would be to triage issues on [2] to make sure that they are assigned to the correct component, assigned to the correct developer and are actually still valid. The reason the

Re: lazy loading build inside queue lock

On Wed, Jan 18, 2017 at 7:53 PM, Surya Gaddipati wrote: > jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:362) > hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:196) >

Re: lazy loading build inside queue lock

Hi oliver, Yes thats the downside of 'preloading' but it would prevent Jenkins from completely freezing at unexpected times . There was some talk of writing lock free implementation of queue. Wondering if that is still on cards . On Wednesday, January 18, 2017 at 6:53:03 PM UTC-6, Surya

Re: lazy loading build inside queue lock

On 2017-01-19 01:53, Surya Gaddipati wrote: Seems like jenkins lazy loads builds inside a queue lock which in turn freezes jenkins because so many places inside jenkins try to lock queue. Is recommended to force lazyload on *all* jobs after jenkins startup to avoid this kind of scenario ?

Re: Maintainer Request for the semantic versioning plugin

Done. Thanks Steven! 2017-01-18 19:02 GMT+01:00 Steve Christou : > Hello Steve, > > Since you gave your permission I do not believe there’s anything you would > need to do. It would rely on me adding myself to the list of maintainers, > and the Jenkins Admins to add me as

Re: Maintainer request Gitlab Plugin

Hi, I have been using this plugin quite extensively, especially with the new pipeline syntax. Submitted a pull request yesterday to support the new syntax #488. There's more to do though and I want to add a few more examples to the readme and pipeline based tests. If I can have commit access I