Re: Plugin end-of-life (EOL) policy

[Basil Crow]

To be honest, I was a bit taken by surprise at the intensity of the
discussions regarding this topic. I was expecting that we could all
agree on some basic criteria, publish a simple statement to that
effect on jenkins.io, and refer to that policy as necessary while
doing work on new features or dependency management. I did not have it
in my mind to write any automation, let alone to introduce "a concept
of […] company/team owner so that we could distinguish plugins
maintained by company contributors and contact companies instead of
individuals who might have left their employer via inactive emails"
(which was explicitly stated as a prerequisite to adopting a plugin
EOL policy). All of this sounds like a large amount of bureaucratic
work, and as a volunteer I have neither the time nor the interest in
pursuing matters of corporate governance. Moreover, I consider it
unlikely that such an approach would be practical.

As a tech lead, I know that making one large and complex deliverable
depend on another large and complex deliverable is likely to result in
delivering neither. My experience is that an incremental approach
works better. My suggestion to the Jenkins community is to focus on
identifying incremental steps to improve the status quo without
getting sidetracked with large and complex deliverables (and
correspondingly lengthy debates). As Bryan Cantrill writes: "When
faced with a decision, determine if there are elements that are common
to both paths, and implement them first, thereby deferring the
decision." One example of such an incremental step forward was my
recent PR to deprecate a handful of older plugins. The more
incremental steps like this we take, the clearer the target becomes.
The target might seem blurry and distant at the beginning, but after
enough steady progress it will come into focus. When that delightful
moment occurs, debate will be pointless since we will be more excited
about racing to the finish line, together.

To the extent that I can identify incremental steps forward, I will
continue to propose them. I believe this is an important challenge for
the Jenkins project, and I want to be a part of the solution. I will
continue to try and help where I can, as my time allows.

-- 
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/CAFwNDjo-f0AnZdNfjRQ04aGP6km4JjbOGrd5Tvh-btRXe0oXHQ%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Oleg Nenashev]

Thanks a lot!

> Then next is 6 years ago. Not holding my breath for these :-).

Me neither. We need Basil's plugin EOL work to land

> I'd like to declare the Digester PR ready-for-merge given the existing
approvals.

Fine with me. The weekly release is out, so it gives maintainers (if any)
one extra week to react until next Tuesday. Should be ok. I will initiate
the contdown

> I don't think however we should block the Digester work until it's done.
This is something I'd like to help deliver for the next weeks & months so
we can use it for Guava.

Yes, I agree with not blocking any pending efforts.

Best regards,
Oleg

On Wed, Jun 2, 2021 at 12:47 AM Baptiste Mathus  wrote:

> Email thread pinging last maintainers' emails taken from git log just
> sent, see the other thread.
>
> Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :
>
>>
>>
>> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
>> écrit :
>>
>>>
>>> > I am not sure exactly sure what you mean by this, but I am certainly
>>> not requesting nor expecting you to support any fallout of this PR. Our
>>> team will obviously step up if something bad arises
>>>
>>> Sorry for confusion, I have no doubt that your team will provide good
>>> support for this change. What I meant is that I am not ready to put my +1
>>> for merging, but I do not block others from proceeding with the merge.
>>>
>>> > What I'm trying to avoid here is stalling this work. We created this
>>> PR on the 1st of March.
>>>
>>> I do not want to stall it either. This is a good technical debt
>>> reduction work, and " I definitely do not want the PR to miss the LTS merge
>>> window" like stated above. I'd love to see it in the September LTS release.
>>> We are also interested to get it in weekly rather sooner than later so that
>>> we can address any regressions if reported.
>>>
>>>
>>> >> and do the better effort in reaching out to plugin maintainers and
>>> getting releases or explicit up-for-adoption where possible.
>>> > Care to elaborate please? IIUC you mean sending an email to the last
>>> known maintainers for plugins that are going to be broken when we merge the
>>> Core PR.
>>>
>>> Yes, I mean sending emails offering to either merge/release the fix or
>>> to put the plugin for adoption. It would be great to finalize Basil's
>>> plugin EOL JEP so that we have this process more or less automated. But now
>>> yes, emails. They can be retrieved from the plugin metadata, Jira or Git
>>> commit history. I can help with these emails as a board member.
>>>
>>
>> OK, I'll do it. I don't plan to wait for their answers though TBH.
>> I'd like to declare the Digester PR ready-for-merge given the existing
>> approvals.
>>
>> For all still unreleased plugins:
>> * For teamconcert, seems there's an active maintainer looking into it.
>> * Then genexus was active last year around early 2020. So I think we
>> could hope for some answer.
>> * Then the next unreleased one is config-rotator, last active 4 years
>> ago. Then next is 6 years ago. Not holding my breath for these :-).
>>
>>
>>
>>> > TBH after this, I fear a bit the Guava upgrade that we want to help on
>>> next...
>>>
>>> Topic for a contributor summit? I also expect difficulties with Guava
>>> upgrade and then Groovy update needed for Java 17 and housekeeping.
>>> Contributor summit could be a good venue to develop strategy for such
>>> massively used components.
>>>
>>
>> Good idea. I'll raise it with the team.
>>
>>
>>> > What, specifically, is the threshold of usage that would cause you to
>>> express concern?
>>>
>>> I do not have a specific threshold at the moment. And I do not think the
>>> installation numbers represent the community importance well. Big Jenkins
>>> setups at enterprises tend to use "exotic" plugins with low installation
>>> numbers, just because they have specific requirements to their environment
>>> and scalability. Admins of these instances also tend to disable sending
>>> usage stats when they discover this option. So I just use personal
>>> expertise which might be biased due to my Hardware/Embedded background. Ask
>>> Daniel or Jesse how often they do a facepalm after hearing about my
>>> use-cases and hacks :)
>>>
>>> Speaking seriously, we could definitely think about defining our
>>> criteria about what we care during such upgrades. Stale plugins and plugins
>>> waiting for adoption for years should not be a blocker for changes we need
>>> as the community.
>>>
>>
>> I like and support this idea.
>> I don't think however we should block the Digester work until it's done.
>> This is something I'd like to help deliver for the next weeks & months so
>> we can use it for Guava.
>>
>>
>>>
>>>
>>> On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:
>>>
 Dear Oleg,

 On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev 
 wrote:
 > I have commented about the plugins removal in another thread.

 In particular, you wrote: "From the list, I am particularly concerned

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Email thread pinging last maintainers' emails taken from git log just sent,
see the other thread.

Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :

>
>
> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
> écrit :
>
>>
>> > I am not sure exactly sure what you mean by this, but I am certainly
>> not requesting nor expecting you to support any fallout of this PR. Our
>> team will obviously step up if something bad arises
>>
>> Sorry for confusion, I have no doubt that your team will provide good
>> support for this change. What I meant is that I am not ready to put my +1
>> for merging, but I do not block others from proceeding with the merge.
>>
>> > What I'm trying to avoid here is stalling this work. We created this PR
>> on the 1st of March.
>>
>> I do not want to stall it either. This is a good technical debt reduction
>> work, and " I definitely do not want the PR to miss the LTS merge window"
>> like stated above. I'd love to see it in the September LTS release. We are
>> also interested to get it in weekly rather sooner than later so that we can
>> address any regressions if reported.
>>
>>
>> >> and do the better effort in reaching out to plugin maintainers and
>> getting releases or explicit up-for-adoption where possible.
>> > Care to elaborate please? IIUC you mean sending an email to the last
>> known maintainers for plugins that are going to be broken when we merge the
>> Core PR.
>>
>> Yes, I mean sending emails offering to either merge/release the fix or to
>> put the plugin for adoption. It would be great to finalize Basil's plugin
>> EOL JEP so that we have this process more or less automated. But now yes,
>> emails. They can be retrieved from the plugin metadata, Jira or Git commit
>> history. I can help with these emails as a board member.
>>
>
> OK, I'll do it. I don't plan to wait for their answers though TBH.
> I'd like to declare the Digester PR ready-for-merge given the existing
> approvals.
>
> For all still unreleased plugins:
> * For teamconcert, seems there's an active maintainer looking into it.
> * Then genexus was active last year around early 2020. So I think we could
> hope for some answer.
> * Then the next unreleased one is config-rotator, last active 4 years ago.
> Then next is 6 years ago. Not holding my breath for these :-).
>
>
>
>> > TBH after this, I fear a bit the Guava upgrade that we want to help on
>> next...
>>
>> Topic for a contributor summit? I also expect difficulties with Guava
>> upgrade and then Groovy update needed for Java 17 and housekeeping.
>> Contributor summit could be a good venue to develop strategy for such
>> massively used components.
>>
>
> Good idea. I'll raise it with the team.
>
>
>> > What, specifically, is the threshold of usage that would cause you to
>> express concern?
>>
>> I do not have a specific threshold at the moment. And I do not think the
>> installation numbers represent the community importance well. Big Jenkins
>> setups at enterprises tend to use "exotic" plugins with low installation
>> numbers, just because they have specific requirements to their environment
>> and scalability. Admins of these instances also tend to disable sending
>> usage stats when they discover this option. So I just use personal
>> expertise which might be biased due to my Hardware/Embedded background. Ask
>> Daniel or Jesse how often they do a facepalm after hearing about my
>> use-cases and hacks :)
>>
>> Speaking seriously, we could definitely think about defining our criteria
>> about what we care during such upgrades. Stale plugins and plugins waiting
>> for adoption for years should not be a blocker for changes we need as the
>> community.
>>
>
> I like and support this idea.
> I don't think however we should block the Digester work until it's done.
> This is something I'd like to help deliver for the next weeks & months so
> we can use it for Guava.
>
>
>>
>>
>> On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:
>>
>>> Dear Oleg,
>>>
>>> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev 
>>> wrote:
>>> > I have commented about the plugins removal in another thread.
>>>
>>> In particular, you wrote: "From the list, I am particularly concerned
>>> about Code Coverage plugins which seemed to be actively used."
>>>
>>> You expressed concern about Emma, a code coverage plugin with 3,148
>>> installations. You did not express concern about BlameSubversion, a
>>> plugin not related to code coverage with 825 installations.
>>>
>>> What, specifically, is the threshold of usage that would cause you to
>>> express concern?
>>>
>>> Thanks,
>>> Basil
>>>
>> --
>> 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
>> 

[Digester/ACTION REQUIRED] Release needed for plugins: teamconcert, vs-code-metrics, BlameSubversion, javatest-report, vss, genexus, synergy, config-rotator, harvest, cmvc to avoid them to break

[Baptiste Mathus]

Hi,

(in CC the Jenkins developers ML)

You're receiving this email because your email appeared in "git log" for
one of the Jenkins plugins listed in the email subject.
This plugin is *going to start breaking with next Jenkins weekly without an
action*.

If you still consider yourself a maintainer of this plugin, please keep
reading and better yet answer this thread.
If not, you can either tell us this plugin is up for adoption, or ignore.


See https://github.com/jenkinsci/jenkins/pull/5320 for the PR for each
plugin.

Each PR needs to be merged AND released.

Thank you

-- Baptiste

-- 
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/CANWgJS4DREUC_33KJFXkpEYb%2BhpBqORne%2B%2BTjK%3DQW_9wmrQ%3D-w%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
écrit :

>
> > I am not sure exactly sure what you mean by this, but I am certainly not
> requesting nor expecting you to support any fallout of this PR. Our team
> will obviously step up if something bad arises
>
> Sorry for confusion, I have no doubt that your team will provide good
> support for this change. What I meant is that I am not ready to put my +1
> for merging, but I do not block others from proceeding with the merge.
>
> > What I'm trying to avoid here is stalling this work. We created this PR
> on the 1st of March.
>
> I do not want to stall it either. This is a good technical debt reduction
> work, and " I definitely do not want the PR to miss the LTS merge window"
> like stated above. I'd love to see it in the September LTS release. We are
> also interested to get it in weekly rather sooner than later so that we can
> address any regressions if reported.
>
>
> >> and do the better effort in reaching out to plugin maintainers and
> getting releases or explicit up-for-adoption where possible.
> > Care to elaborate please? IIUC you mean sending an email to the last
> known maintainers for plugins that are going to be broken when we merge the
> Core PR.
>
> Yes, I mean sending emails offering to either merge/release the fix or to
> put the plugin for adoption. It would be great to finalize Basil's plugin
> EOL JEP so that we have this process more or less automated. But now yes,
> emails. They can be retrieved from the plugin metadata, Jira or Git commit
> history. I can help with these emails as a board member.
>

OK, I'll do it. I don't plan to wait for their answers though TBH.
I'd like to declare the Digester PR ready-for-merge given the existing
approvals.

For all still unreleased plugins:
* For teamconcert, seems there's an active maintainer looking into it.
* Then genexus was active last year around early 2020. So I think we could
hope for some answer.
* Then the next unreleased one is config-rotator, last active 4 years ago.
Then next is 6 years ago. Not holding my breath for these :-).



> > TBH after this, I fear a bit the Guava upgrade that we want to help on
> next...
>
> Topic for a contributor summit? I also expect difficulties with Guava
> upgrade and then Groovy update needed for Java 17 and housekeeping.
> Contributor summit could be a good venue to develop strategy for such
> massively used components.
>

Good idea. I'll raise it with the team.


> > What, specifically, is the threshold of usage that would cause you to
> express concern?
>
> I do not have a specific threshold at the moment. And I do not think the
> installation numbers represent the community importance well. Big Jenkins
> setups at enterprises tend to use "exotic" plugins with low installation
> numbers, just because they have specific requirements to their environment
> and scalability. Admins of these instances also tend to disable sending
> usage stats when they discover this option. So I just use personal
> expertise which might be biased due to my Hardware/Embedded background. Ask
> Daniel or Jesse how often they do a facepalm after hearing about my
> use-cases and hacks :)
>
> Speaking seriously, we could definitely think about defining our criteria
> about what we care during such upgrades. Stale plugins and plugins waiting
> for adoption for years should not be a blocker for changes we need as the
> community.
>

I like and support this idea.
I don't think however we should block the Digester work until it's done.
This is something I'd like to help deliver for the next weeks & months so
we can use it for Guava.


>
>
> On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:
>
>> Dear Oleg,
>>
>> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev 
>> wrote:
>> > I have commented about the plugins removal in another thread.
>>
>> In particular, you wrote: "From the list, I am particularly concerned
>> about Code Coverage plugins which seemed to be actively used."
>>
>> You expressed concern about Emma, a code coverage plugin with 3,148
>> installations. You did not express concern about BlameSubversion, a
>> plugin not related to code coverage with 825 installations.
>>
>> What, specifically, is the threshold of usage that would cause you to
>> express concern?
>>
>> Thanks,
>> Basil
>>
> --
> 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/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from 

Re: [Digester] Adopt plugins emma & cloverphp

[Oleg Nenashev]

I am definitely +1 for adoption though the pull requests were merged too 
early IMHO.
We usually have a 2-weeks response timeout, and we are yet to approve the 
Plugin EOL policy from Basil.

On Monday, May 31, 2021 at 11:24:24 PM UTC+2 Baptiste Mathus wrote:

> PR 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1975
>
> Le lun. 31 mai 2021 à 23:10, Baptiste Mathus  a écrit :
>
>> In CC, 
>> Seiji Sogabe & patrick-brueckner for cloverphp...
>> brandt & Manolo Carrasco for emma.
>>
>> Hi all, I'd like to adopt these two plugins to be able to release them 
>> with the adaptation for Digester.
>>
>> For perspective, both plugins' last activity & last release were in 2015:
>>
>>- https://github.com/jenkinsci/emma-plugin
>>- https://github.com/jenkinsci/cloverphp-plugin
>>
>> I'll create the permissions PR soon.
>>
>> Thanks
>>
>> -- Baptiste
>>
>>

-- 
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/8ea0d310-f328-4d64-a429-8a02c4b47504n%40googlegroups.com.

Re: I would like to become committer/maintainer on a plugin

[Oleg Nenashev]

Added Sven Schönung, the current Calendar View Plugin maintainer, to Cc.
If we get approval for the plugin adoption, we can transfer the permissions
quickly


On Tue, Jun 1, 2021 at 7:26 PM Oleg Nenashev  wrote:

> Hi Roland,
>
> Thanks for your contributions! Indeed it does not look that the Calendar
> View plugin is actively maintained.
> It has not been put for adoption either, so we will need to ping the
> maintainer and wait for a 2 weeks timeout if no response.
> I will help with that
>
> Best regards,
> Oleg Nenashev
>
>
> On Monday, May 31, 2021 at 9:53:23 PM UTC+2 roland...@gmail.com wrote:
>
>> Hello,
>>
>> I would like to become a committer or even maintainer on the Calendar
>> View Plugin:
>>
>> https://plugins.jenkins.io/calendar-view/
>>
>> I want to merge at least the following Pull Requests:
>> - https://github.com/jenkinsci/calendar-view-plugin/pull/21
>> - https://github.com/jenkinsci/calendar-view-plugin/pull/22
>>
>> GitHub username: malice00
>> Jenkins infra username: malice00
>>
>> Until now I have only created some PRs on plugins, so a link to all
>> necessary information on being a committer/maintainer would be great!
>>
>> Thank you.
>>
>> Roland Asmann
>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> --
> 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/I03rPPkYSTY/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/d5ba2a9f-a420-4288-84c1-44f2f6fa1581n%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/CAPfivLAe4qdgRDjwLbh7Qqo7nYwCh__o7Cy%2ByGeRCHU803Ehcg%40mail.gmail.com.

Re: I would like to become committer/maintainer on a plugin

[Oleg Nenashev]

Hi Roland,

Thanks for your contributions! Indeed it does not look that the Calendar 
View plugin is actively maintained.
It has not been put for adoption either, so we will need to ping the 
maintainer and wait for a 2 weeks timeout if no response.
I will help with that

Best regards,
Oleg Nenashev


On Monday, May 31, 2021 at 9:53:23 PM UTC+2 roland...@gmail.com wrote:

> Hello,
>
> I would like to become a committer or even maintainer on the Calendar 
> View Plugin:
>
> https://plugins.jenkins.io/calendar-view/
>
> I want to merge at least the following Pull Requests:
> - https://github.com/jenkinsci/calendar-view-plugin/pull/21
> - https://github.com/jenkinsci/calendar-view-plugin/pull/22
>
> GitHub username: malice00
> Jenkins infra username: malice00
>
> Until now I have only created some PRs on plugins, so a link to all 
> necessary information on being a committer/maintainer would be great!
>
> Thank you.
>
> Roland Asmann
>
> -- 
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>

-- 
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/d5ba2a9f-a420-4288-84c1-44f2f6fa1581n%40googlegroups.com.

Looking for information about software production process

[Giacomo Checchini]

Hi everyone,
other three students and I are working on a project/report for our software 
engineering course of University of Padova (Italy).
We had to choose an open source project to analyze under some aspects like 
software production process and code metrics (in particular CK, LLOC, CC).
We would kindly ask if there was anyone willing to help us answer some 
questions.
Thanks for your attention.
Best Regards.

Giacomo Checchini
giacomo.checch...@studenti.unipd.it

-- 
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/022da3f5-b1a0-4c9c-a554-b229e28bcc93n%40googlegroups.com.

Re: Jenkins 3.x

[Oleg Nenashev]

Hi all,

Just a quick update for this and the related discussions:

   - As we discussed at the governance meeting, the Jenkins 3 discussions 
   were scheduled to the Jenkins Contributor Summit on June 25th 
   . 
   My plan was to have at least 3 hours of discussion of Jenkins 3 there, with 
   focus on delivering changes needed for reducing maintenance overhead, Java 
   17 support, and Jenkins paradigm changes to reflect the modern CasC 
   ecosystem and cloud environments.
   - I am sad to announce that I will be unable to drive this topic due to 
   the conflict of interest I was unable to resolve.
   - If there is any contributor interested in driving the conversation for 
   this topic, this is really good time to step up. I will be happy to help as 
   a contributor summit organizer.
   
Thanks to all community members who contributed by providing feedback and 
reviews for some of my ideas in other channels.I might have some time to 
drive this effort in the future, but I cannot do it now.

Thanks for understanding,
Oleg Nenashev
Engineer, CloudBees

On Wednesday, January 27, 2021 at 8:09:46 PM UTC+1 Jesse Glick wrote:

> On Wed, Jan 27, 2021 at 1:18 PM Tim Jacomb  wrote:
>
>> > Date based
>> […] any thoughts on the effort involved here in release automation?
>>
>
> I think this would most easily be done by ditching `maven-release-plugin`. 
> We have already done the tricky bits with `flatten-maven-plugin` etc. in 
> JEP-305. The JEP-229 system is the safest. You can also create a special 
> variant like
>
> mvn -Drevision=$(date -I) -Dchangelist= deploy
>
> plus some profile activation for `maven-javadoc-plugin` & 
> `maven-source-plugin` similar to what `produce-incrementals` does, plus 
> manual tagging, with the downside that snapshot & incremental builds will 
> not easily or safely compare properly to releases.
>

-- 
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/0ff2a4e6-564f-4822-b639-c0fd93fe515an%40googlegroups.com.

Re: Where to implement GitLab Branch Source MR Naming change

[Christoph Obexer]

Thanks for the pointer!

I came up with theese changes to implement the `Job.displayName` variant: 
https://github.com/jenkinsci/branch-api-plugin/pull/254 The tests are 
really unhappy about my call to `getAction` =(

However I only consider this a POC at this point and would like to get 
feedback from the maintainers on the change in general before spending the 
required time to implement this properly.

GitHub didn't assign reviewers automatically... how do I request proper 
review for this broad change?

On Tuesday, 25 May 2021 at 21:32:36 UTC+2 Jesse Glick wrote:

> On Tue, May 25, 2021 at 1:41 PM cob...@gmail.com  wrote:
>
>> Or do you recommend to implement this feature in the scm-api plugin?
>>
>
> The API is already defined, and might already be implemented in 
> `gitlab-branch-source` (no idea offhand): 
> https://javadoc.jenkins.io/plugin/scm-api/jenkins/scm/api/metadata/ObjectMetadataAction.html#getObjectDisplayName--
>  
>
> As to how it is *used*, that is another question, outside the control 
> of `gitlab-branch-source`. The `Job.displayName` could be set by the 
> `branch-api` plugin, though it is probably better to set a 
> `Job.description` (for display in the project index page) and maybe add a 
> new list view column to the `change-requests` view.
>

-- 
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/991caede-223f-4b98-a7ac-97198e63713dn%40googlegroups.com.

Re: [jenkinsci-board] Proposal: Jenkins funding page on LFX Crowdfunding

[Ullrich Hafner]

> Am 01.06.2021 um 07:45 schrieb Oleg Nenashev :
> 
> Thanks to Ulli for the feedback and for offering help! Restored the dev list 
> in CC.
> 
> Seems that the bureaucracy is starting to increase in several areas of 
> Jenkins now, but maybe this is a very subjective view.  (But I am not a fan 
> of creating a new complex process here.)
> Any suggestions on reducing bureaucracy would be very welcome. Sorry if I 
> push for having clear and public processes in some areas too much, happy to 
> discuss it at the Governance meeting. Regarding funding, I do not think the 
> process becomes more complex TBH...
> We already approve most of the expenses at the governance meetings. Nothing 
> changes there except this fact being documented somewhere
> Tyler used to do budget summary reporting before. It is generally nice to do 
> so to avoid situations like we had with ffis.de . Note that 
> our earnings and spendings will become fully public once we move from SPI to 
> LFX Crowdfunding. Everyone will be able to see our treasury state on 
> https://crowdfunding.lfx.linuxfoundation.org/projects/jenkins 
>  . So sending 
> a summary to the dev list 1-2 times per year seems to be a low effort which 
> is not even worth automation.
> The main time sink would have been getting information about our regular 
> spendings. Fortunately, Olivier has already aggregated this info for the 
> Jenkins infrastructure. I am not aware about any other regular spendings, so 
> we would just need 
> Any suggestions are welcome. For example, we could agree to not do budget 
> reporting and just provide a link. Anyway I will try to make one for the 
> current state. I started it a few months ago, a good opportunity to finish it 
> finally.

Yes, that would be helpful to see how much work is involved.

> 
> Maybe it helps to make that clear with an example report.
> So far we had only one expense report from Sladyn on CommunityBridge. THis 
> would be a dated example. So we would need a new transaction to happen. 
> 

Ok, then we can do this once it is required. 

> helping others with doing donations/stipend payments and reimbursements 
> through LFX ... I have no idea what should be done here? We do not have 
> stipends currently, or do we? What „others" do you mean?
> Just doing Q for cases which are not documented well on the Jenkins or LFX 
> Crowdfunding site. And ideally documenting missing cases so we have a good 
> FAQ. Some related docs:
> JEP-15 - Jenkins funding on LFX Crowdfunding 
>  (needs updates) 
> JEP-8 - GSoC funding and expenses 
> 
> JEP-12 - Travel grant program 
> 
> Signing off (aka rubber stamping) the expense report after the reviews...  
> What does that mean for me as an individual? What responsible do I have?   
>  There are 2 steps:
> Do final check that the expense approval process was followed
> Click a few buttons in Expensify
> Also that likely involves being a point of contact for the LFX Crowdfunding 
> team, LF finance and reimbursement requesters if/when something goes wrong in 
> payments.
> 

Sorry, seems that I picked the wrong English term. What I meant: when I am 
signing an official document (about a financial topic) I am somehow liable (?) 
in a juristic way. What happens if the document I am signing contains errors, 
can somebody sue me as an individual? I do not want to have such a 
responsibility.  

> Best regards,
> Oleg Nenashev
> 
> 
> On Mon, May 31, 2021 at 11:30 PM Ullrich Hafner  > wrote:
> The process in total looks good to me!
> 
> Seems that the bureaucracy is starting to increase in several areas of 
> Jenkins now, but maybe this is a very subjective view. 
> 
> I can help you with getting the action items done. (But I am not a fan of 
> creating a new complex process here.)
> 
>> Am 31.05.2021 um 13:31 schrieb Oleg Nenashev > >:
>> 
>> Thanks to Gavin for bringing up the over-commitment concern. I can totally 
>> relate to that, and I would not like to take the role just to do treasury 
>> management single handedly. FTR the role of the treasurer includes multiple 
>> parts:
>> monitoring and reporting on budgets. This assignment can be load balanced 
>> between contributors, Treasurer "just" needs to ensure it happens. Taking 
>> our small cash flows, it won't take much time
> Yes, that looks like an action item that can be done by everybody, so I am 
> happy to help here. 
>> helping others with doing donations/stipend payments and reimbursements 
>> through LFX. I have already figured out the process, can document. It rather 
>> requires patience and regular pings. Can be shared between contributors
> I have no idea what should be done here? We do not have stipends currently, 

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Oleg Nenashev]

> I am not sure exactly sure what you mean by this, but I am certainly not 
requesting nor expecting you to support any fallout of this PR. Our team 
will obviously step up if something bad arises 

Sorry for confusion, I have no doubt that your team will provide good 
support for this change. What I meant is that I am not ready to put my +1 
for merging, but I do not block others from proceeding with the merge.

> What I'm trying to avoid here is stalling this work. We created this PR 
on the 1st of March.  

I do not want to stall it either. This is a good technical debt reduction 
work, and " I definitely do not want the PR to miss the LTS merge window" 
like stated above. I'd love to see it in the September LTS release. We are 
also interested to get it in weekly rather sooner than later so that we can 
address any regressions if reported. 


>> and do the better effort in reaching out to plugin maintainers and 
getting releases or explicit up-for-adoption where possible.
> Care to elaborate please? IIUC you mean sending an email to the last 
known maintainers for plugins that are going to be broken when we merge the 
Core PR.
 
Yes, I mean sending emails offering to either merge/release the fix or to 
put the plugin for adoption. It would be great to finalize Basil's plugin 
EOL JEP so that we have this process more or less automated. But now yes, 
emails. They can be retrieved from the plugin metadata, Jira or Git commit 
history. I can help with these emails as a board member.

> TBH after this, I fear a bit the Guava upgrade that we want to help on 
next... 

Topic for a contributor summit? I also expect difficulties with Guava 
upgrade and then Groovy update needed for Java 17 and housekeeping.
Contributor summit could be a good venue to develop strategy for such 
massively used components.

> What, specifically, is the threshold of usage that would cause you to 
express concern? 

I do not have a specific threshold at the moment. And I do not think the 
installation numbers represent the community importance well. Big Jenkins 
setups at enterprises tend to use "exotic" plugins with low installation 
numbers, just because they have specific requirements to their environment 
and scalability. Admins of these instances also tend to disable sending 
usage stats when they discover this option. So I just use personal 
expertise which might be biased due to my Hardware/Embedded background. Ask 
Daniel or Jesse how often they do a facepalm after hearing about my 
use-cases and hacks :)

Speaking seriously, we could definitely think about defining our criteria 
about what we care during such upgrades. Stale plugins and plugins waiting 
for adoption for years should not be a blocker for changes we need as the 
community.


On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:

> Dear Oleg,
>
> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev  
> wrote:
> > I have commented about the plugins removal in another thread.
>
> In particular, you wrote: "From the list, I am particularly concerned
> about Code Coverage plugins which seemed to be actively used."
>
> You expressed concern about Emma, a code coverage plugin with 3,148
> installations. You did not express concern about BlameSubversion, a
> plugin not related to code coverage with 825 installations.
>
> What, specifically, is the threshold of usage that would cause you to
> express concern?
>
> Thanks,
> Basil
>

-- 
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/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com.