Hi Oleg,
Thanks for driving this.
Once we are allowed to have a second Github Organization, I would be very
interested to experiment with it for the jenkins-infra organization.
On Monday, 3 May 2021 at 22:24:44 UTC+2 Oleg Nenashev wrote:
> Thanks for the interest Daniel!
>
> >> Would you like
On Mon, May 3, 2021 at 10:24 PM Oleg Nenashev
wrote:
> >> Would you like to participate as a contributor?
> > What does this entail?
>
> That's a good question, to be seen. As a part of the pilot project we will
> need:
>
>- Try out LFX Security 2.0 and configure it for some of our projects
>
Some people like being the default assignee. Others prefer it stay
unassigned until someone starts working on it.
It's your call. Isn't hard to change either
On Mon., May 3, 2021, 3:03 p.m. Jim Klimov, wrote:
> On May 3, 2021 8:34:49 PM UTC, Oleg Nenashev
> wrote:
> >Hi Jim,
> >
> >I have grant
On May 3, 2021 8:34:49 PM UTC, Oleg Nenashev wrote:
>Hi Jim,
>
>I have granted you permissions. Let me know whether you want to be a
>default assignee in Jira.
>To do the releases, you will need to
>update
>https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/p
>
> In the case changing "Sponsor" -> "Champion/Owner" and adding "(New role)
> Sponsor", I'm not convinced there's a huge win there. We already define a
> "Reviewer" role as an alias for "BDFL and BDFL Delegate". If we replace
> the "BDFL Delegate" field with "Reivewer" wouldn't that be suffici
As one of the "Sponsors" of JEP-1, I should probably weigh in.
I support streamlining the JEP process any way the community sees fit to
do. Removing the BDFL and BDFL Delegate, replacing them with the
Governance Board certainly makes sense at this point. Howver, I don't like
changing the meaning
> There is discussion in https://issues.jenkins.io/browse/JENKINS-26463 and
I actually started a prototype years ago. Some changes made since then make
the task a bit easier.
I also started a PoC a while ago and then failed. Indeed it should be
easier now.
Reworking the structure could also all
Hi Jim,
I have granted you permissions. Let me know whether you want to be a
default assignee in Jira.
To do the releases, you will need to
update
https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-multiple-scms.yml
Best regards,
Oleg
On Monday, May
> Having more motivative contributors is crucial for the community. Sharing
your routine or stories to us might be a good way to let those who is
interested in the community contribution even leading. If there’s any
chances I’d like to take some responsibility.
Thanks, it is much appreciated. J
Thanks for the interest Daniel!
>> Would you like to participate as a contributor?
> What does this entail?
That's a good question, to be seen. As a part of the pilot project we will
need:
- Try out LFX Security 2.0 and configure it for some of our projects
- Explore options for filtering
Thanks again for driving this, Oleg!
> On 3. May 2021, at 19:14, Oleg Nenashev wrote:
>
> The proposal is to start the pilot from a small list of the repositories
> controlled by the pilot project participants: Jenkins core, its libraries,
> and some plugins from maintainers who are intereste
+1 from me. Thanks for being willing to adopt the plugin.
On Sun, May 2, 2021 at 7:29 PM Jim Klimov wrote:
> Hello,
>
> I'd hereby like to ask to be anointed a maintainer for
> https://plugins.jenkins.io/multiple-scms/ to keep it sufficiently in line
> with modern Jenkins requirements such as t
On Mon, May 3, 2021 at 3:46 AM Daniel Beck wrote:
> Something more extensible, with version ranges like we do for security
> warnings could help here:
> "This plugin is likely to break the UI once you update Jenkins to 2.277.x"
> and "no fix is available" or "update to version X or newer".
>
FYI
On Sun, May 2, 2021 at 9:29 PM Jim Klimov wrote:
> pipelines with several custom-argument checkout steps achieve a similar
> effect […] probably being a reason to not develop a pipeline integration
> for this plugin
Indeed, this plugin is not necessary for Pipeline users.
> but for legacy job
On Fri, Apr 30, 2021 at 6:07 PM Oleg Nenashev
wrote:
> do you have any performance metrics?
I did not spend much time doing exacting measurements, but it does start
basically instantly, unlike the JAR version. Of course it then needs to
contact the Jenkins service, which could be faster or slow
Hi all,
I am not sure this is the last conversation about the JEPs process, but as
a JEP Editor I would like to recover it. Currently the JEP process does NOT
workm neither for the original inspiration s nor for the documentation
purposes. We have multiple JEPs created recently, but they get st
Hi Baptiste,
Thanks a lot for this work! Commons Digester is definitely a legacy that we
should rather remove from Jenkins. It should be perfectly fine as long as
we provide an upgrade path in plugins, timely deprecate and announce the
removal. We're doing pretty much the same process for Ruby
On Tue, Apr 27, 2021 at 4:00 AM Basil Crow wrote:
> Abandoned plugins cause friction for both Jenkins users and contributors
> alike.
>
> They cause friction for users because they are unlikely to be simpatico
> with newer features like Pipeline. In the worst case, they are downright
> incompatib
18 matches
Mail list logo
