Re: Proposal: newsletter mailing list for contributor announcements

['Gavin Mogan' via Jenkins Developers]

I added a rss bot to jenkinsci/jenkins gitter channel, but since I don't
have admin in the gitter i can't add subscriptions
in theory, ` !rss subscribe https://feeds.feedburner.com/ContinuousBlog/`
should be enough to make it work. If that does, we can have rss from
discourse too

On Fri, Jun 11, 2021 at 3:04 PM Oleg Nenashev 
wrote:

> After the introduction of community.jenkins.io, maybe creating a mailing
> list does not make sense anymore.
> There is already a category for announcements created by Olivier:
> https://community.jenkins.io/t/about-the-announcement-category/40
>
> Instead of the original idea, I suggest the following:
>
>- We create categories for user and contributor announcements on
>Discourse. Maybe topic in those categories should be locked by default, but
>I would rather keep them open to allow live discussion
>- Nice2Have: Connect the announcement feeds to...
>   - Subscription mailing list (maybe)
>   - Atom Feeds
>   - Telegram channels
>   - IRC
>   - etc
>
> Best regards,
> Oleg
> On Tuesday, March 23, 2021 at 11:01:53 PM UTC+1 Oleg Nenashev wrote:
>
>> > So while the concept is a good one, I have concerns about the
>> execution. Lets say you had a new announcement next week, would you just
>> post to that list, knowing that most people havn't signed up for it yet, or
>> would you cross post every announcement to dev, docs, infra, and
>> announcements for the next year or so?
>>
>> I think that the existing mailing lists should remain the source of
>> truth. One of the key reasons - they allow the discussion. I consider the
>> announcements channel as a secondary notification channel where we might be
>> sending summaries and reposting announcements, but not a replacement for
>> any existing channel.
>>
>> > Who would have access to post to it? Anyone? Board members? sig leads?
>>
>> TBD. Taking the intent above, it should be rather a small set of users.
>> Maybe we could apply email-as-code by using GitHub Actions or Jenkins
>> Pipelines (e.g. https://github.com/marketplace/actions/send-email for
>> the first option)
>>
>> > My vote is to reach out to discourse for a sponsorship, and move all
>> async communication there
>>
>> It is something we could discuss and try out. Not sure it addresses the
>> original purpose of the thread, I would not like to boil the ocean now.
>> But yes, it is definitely an option we could consider.
>>
>>
>> On Tue, Mar 23, 2021 at 10:30 PM 'Gavin Mogan' via Jenkins Developers <
>> jenkin...@googlegroups.com> wrote:
>>
>>> So while the concept is a good one, I have concerns about the execution.
>>> Lets say you had a new announcement next week, would you just post to that
>>> list, knowing that most people havn't signed up for it yet, or would you
>>> cross post every announcement to dev, docs, infra, and announcements for
>>> the next year or so? Who would have access to post to it? Anyone? Board
>>> members? sig leads?
>>>
>>> Its the same problem lots of reddit subredits have. People find a sub
>>> list too noisy, create more specialized subs, and then both become more
>>> empty. I'm scared of that happening here Especially since dev mailing list
>>> only gets a couple posts a day.
>>>
>>> My vote is to reach out to discourse for a sponsorship, and move all
>>> async communication there. Instead of having like 8 mailing lists, and
>>> having to know which one to use, and new users to know which ones to sign
>>> up for, it would be a single thing. And if people post to the wrong form
>>> then it could be moved to the right place, or in the case of spam outright
>>> deleted. Discourse has email support so for those who prefer email, they
>>> can still post and reply via email. Plus it would mean it wouldn't be
>>> google and we could have ldap, google, github and twitter logins like we do
>>> for.
>>>
>>> (Full disclosure, I'd love to centralize on discourse for async and
>>> matrix for sync)
>>>
>>> Not at all blocking this idea, just voicing concerns.
>>>
>>> Gavin
>>>
>>> On Tue, Mar 23, 2021 at 2:23 PM Tim Jacomb  wrote:
>>>
 jenkins-dev-announce ?

 On Tue, 23 Mar 2021 at 13:53, Oleg Nenashev 
 wrote:

> I would have been in favor of "jenkins-announcement" if it was a user
> newsletter (which we could introduce as well).
> In this case I am rather about contacting contributors specifically,
> and I'd like to distinguish the name somehow.
> Any suggestions will be much appreciated.
>
> On Tue, Mar 23, 2021 at 12:13 PM 'Olblak' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
>
>> Hi Everybody,
>>
>> I am definitely in favor of a new low traffic channel to distribute
>> major news, I share Richard's opinion, I also find it difficult to keep 
>> up
>> in the dev mailing list.
>> Personally, I would suggest using something more generic like
>> "jenkins-announcement" and maybe using tags in the subject but we 

Re: Proposal: newsletter mailing list for contributor announcements

[Oleg Nenashev]

After the introduction of community.jenkins.io, maybe creating a mailing 
list does not make sense anymore.
There is already a category for announcements created by Olivier: 
https://community.jenkins.io/t/about-the-announcement-category/40

Instead of the original idea, I suggest the following:

   - We create categories for user and contributor announcements on 
   Discourse. Maybe topic in those categories should be locked by default, but 
   I would rather keep them open to allow live discussion
   - Nice2Have: Connect the announcement feeds to...
  - Subscription mailing list (maybe)
  - Atom Feeds
  - Telegram channels
  - IRC
  - etc
   
Best regards,
Oleg
On Tuesday, March 23, 2021 at 11:01:53 PM UTC+1 Oleg Nenashev wrote:

> > So while the concept is a good one, I have concerns about the execution. 
> Lets say you had a new announcement next week, would you just post to that 
> list, knowing that most people havn't signed up for it yet, or would you 
> cross post every announcement to dev, docs, infra, and announcements for 
> the next year or so? 
>
> I think that the existing mailing lists should remain the source of truth. 
> One of the key reasons - they allow the discussion. I consider the 
> announcements channel as a secondary notification channel where we might be 
> sending summaries and reposting announcements, but not a replacement for 
> any existing channel.
>
> > Who would have access to post to it? Anyone? Board members? sig leads?
>
> TBD. Taking the intent above, it should be rather a small set of users.
> Maybe we could apply email-as-code by using GitHub Actions or Jenkins 
> Pipelines (e.g. https://github.com/marketplace/actions/send-email for the 
> first option)
>
> > My vote is to reach out to discourse for a sponsorship, and move all 
> async communication there
>
> It is something we could discuss and try out. Not sure it addresses the 
> original purpose of the thread, I would not like to boil the ocean now.
> But yes, it is definitely an option we could consider.
>
>
> On Tue, Mar 23, 2021 at 10:30 PM 'Gavin Mogan' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
>
>> So while the concept is a good one, I have concerns about the execution. 
>> Lets say you had a new announcement next week, would you just post to that 
>> list, knowing that most people havn't signed up for it yet, or would you 
>> cross post every announcement to dev, docs, infra, and announcements for 
>> the next year or so? Who would have access to post to it? Anyone? Board 
>> members? sig leads?
>>
>> Its the same problem lots of reddit subredits have. People find a sub 
>> list too noisy, create more specialized subs, and then both become more 
>> empty. I'm scared of that happening here Especially since dev mailing list 
>> only gets a couple posts a day.
>>
>> My vote is to reach out to discourse for a sponsorship, and move all 
>> async communication there. Instead of having like 8 mailing lists, and 
>> having to know which one to use, and new users to know which ones to sign 
>> up for, it would be a single thing. And if people post to the wrong form 
>> then it could be moved to the right place, or in the case of spam outright 
>> deleted. Discourse has email support so for those who prefer email, they 
>> can still post and reply via email. Plus it would mean it wouldn't be 
>> google and we could have ldap, google, github and twitter logins like we do 
>> for.
>>
>> (Full disclosure, I'd love to centralize on discourse for async and 
>> matrix for sync)
>>
>> Not at all blocking this idea, just voicing concerns.
>>
>> Gavin
>>
>> On Tue, Mar 23, 2021 at 2:23 PM Tim Jacomb  wrote:
>>
>>> jenkins-dev-announce ?
>>>
>>> On Tue, 23 Mar 2021 at 13:53, Oleg Nenashev  wrote:
>>>
 I would have been in favor of "jenkins-announcement" if it was a user 
 newsletter (which we could introduce as well).
 In this case I am rather about contacting contributors specifically, 
 and I'd like to distinguish the name somehow.
 Any suggestions will be much appreciated.

 On Tue, Mar 23, 2021 at 12:13 PM 'Olblak' via Jenkins Developers <
 jenkin...@googlegroups.com> wrote:

> Hi Everybody, 
>
> I am definitely in favor of a new low traffic channel to distribute 
> major news, I share Richard's opinion, I also find it difficult to keep 
> up 
> in the dev mailing list.
> Personally, I would suggest using something more generic like 
> "jenkins-announcement" and maybe using tags in the subject but we should 
> keep it read-only and very low traffic
>
> While I am not a big fan of the Google group, it remains the easiest 
> solution :/.
> I wouldn't be in favor of using the Sendgrid mailing list, mainly for 
> access management. 
>
> On Monday, 22 March 2021 at 10:33:47 UTC+1 Oleg Nenashev wrote:
>
>> > I know it's stretching the scope of what you are talking about, but 

Re: HELP NEEDED - Jenkins contributor summit on Jun 25

[Baptiste Mathus]

I'm sorry to be so late on this... I am going to write here for visibility,
and I'll also add or see to add it correctly the sheet initiated by Oleg.

1. I would like to help facilitate a conversation on Guava upgrade in
Jenkins Core.
As you know, this work is already somehow started. I'd like us to take the
summit opportunity to decide on next steps, approaches.
Our team at CloudBees is committed to help on this subject.

2. Plugin EOL policy // plugin maintenance status
I think these two subjects would serve us as a community to keep moving
Jenkins forward.
For the commons-digester:2.1 recent removal for instance, I think we spent
a subtantial amount of effort on plugins nobody should use anymore since a
long time.
If we had had such a policy, we could have saved a lot of energy together.

3. Company/team ownership for plugins
As an ex-HOSTING team member and a contributor since a few years, I think
we need to have a clearer stance for companies to implement a Jenkins
plugin for their software.
It happens regularly than a company, not intimate with the Jenkins
Project's governance, will request commit access to a plugin they think
they own somehow. (e.g. HOSTING-901, HOSTING-346, HOSTING-288, HOSTING-134,
and we could go on)
Only then they discover that from the Jenkins Project's standpoint, they do
not *exist*. An ex-employee that may have even left a given company could
disagree to let commit rights go and they would be entitled to this
(fortunately didn't happen yet, to my knowledge).

The other case I've got in mind is the "team" concept. That's the one I'm
most interested in personally. For example, when people move between teams
in our company etc., we usually need to update many files in RPU and
request commit access in various repositories.
If we could have an official concept for teams within the Jenkins Project,
I think we could set up special GH teams (for example one for ours at
CloudBees) + create possibly such a concept for it inside RPU to define
this only once.
I think this is already doable (we already have the core team within GH
e.g.), and we could request an ad-hoc implementation and move on. But I
think there's merit in defining something generalized for the Jenkins
Project's governance.

Thanks for reading :). I definitely didn't plan to send such a long email.

Have a great weeked everyone.

Le jeu. 10 juin 2021 à 14:27, Kara de la Marck  a
écrit :

> Thanks for your suggestion, Oleg!
>
> It's likely better for us to keep all the updates together for the
> Contributors Summit, that way they will be easier to consume for all
> interested parties.
>
> Would it be possible for a contributor who can't make it on the 25th to
> record an update on behalf of a SIG or track?  And that this pre-recorded
> update would be shown during the allocated time on the 25th?
>
>
> On Thu, Jun 10, 2021 at 2:03 AM Oleg Nenashev 
> wrote:
>
>> Hi Kara,
>>
>> Thanks for the feedback and for helping with the Cloud Native SIG! I
>> understand the timezones are imperfect. Apart from moving a meeting to an
>> earlier slot, we have an option to do the Cloud Native SIG meeting on
>> Saturday, Jun 26.
>>
>> I can host meetings if they are after 4AM UTC. Maybe Rick or Himandri
>> would be also available.
>>
>> BR, Oleg
>>
>>
>> On Wed, Jun 9, 2021, 21:50 Kara de la Marck 
>> wrote:
>>
>>> Hi all,
>>>
>>> Thank you for organizing the Contributor Summit and its schedule, Oleg
>>> and Olivier.
>>>
>>> I'm very happy to lead on the Cloud Native track to ensure that we have
>>> a speaker to summarize recent highlights in the Cloud Native SIG; ideally,
>>> this would be an active community member.
>>>
>>> Please note that the time as currently scheduled will be too late for
>>> our Cloud Native SIG participants and contributors in India (and APAC
>>> generally).
>>>
>>>
>>>
>>> On Wed, Jun 9, 2021 at 11:48 AM 'Olblak' via Jenkins Developers <
>>> jenkinsci-dev@googlegroups.com> wrote:
>>>
 Thanks, Oleg for driving this.

 Yesterday, Mark suggested to me to move the contributor track as early
 as possible to have as many people from AMER and EMEA in an interactive
 session.
 This an idea that I like very much and I would like to discuss it
 tomorrow.
 So we would have "project update", "contributor track", "SIG update",
 "CDF project collaboration" as I am suggesting in the google sheet.



 On Wed, Jun 9, 2021, at 6:45 AM, Oleg Nenashev wrote:

 Thanks to Olivier for the contributions and willing to help! Based on
 the feedback in the voting poll, I created a meeting on Thursday, 1PM UTC.
 At this meeting we will agree on the agenda and split the
 organization/moderation tasks. Everyone is welcome to participate, and I
 will also try to record this meeting.

 Links:

 * [Calendar Link](
 

Re: ASM in core

[Basil Crow]

On Fri, Jun 11, 2021 at 2:19 AM Robert Sandell  wrote:
>
> Some historical context to know where we "old timers" are coming from :)
> https://kohsuke.org/2012/03/03/potd-package-renamed-asm/

Thanks for providing this context, Robert! I have a tremendous amount
of respect for all the old-timers in this project. Thanks for having
the patience to explain this to a newcomer like me.

I dug up the original post [1] where Kohsuke laid out his complaints
about ASM. All these complaints seem completely legitimate in the
context of ASM 3 in 2010, which definitely seems like it broke
compatibility with ASM 2.

I know these scars run deep, but I think we should re-examine things
in 2021. As of commit 6a0e7842de436225f3866d3567834c6285107114 in ASM
5.2, ASM added signature tests to avoid breaking backward binary
compatibility with any version >= 4.0. These signature tests are still
present in "src/test/resources" on the latest version of ASM. So ASM
appears to take compatibility seriously these days.

We shouldn't be as nervous about compatibility between ASM 5 and ASM 9
in 2021 as we were about compatibility between ASM 2 and ASM 3 in
2010. Things have changed in the intervening decade.

> That's why me and James and others are very very wary of bumping the asm 
> dependencies, I think even more wary than for Guava, because there isn't 
> enough code coverage due to how the classpath is during unit testing.

Again, I know these scars run deep, but allow me to reiterate that
core has _already_ bumped ASM to latest in December 2020, in my
opinion unintentionally, as a result of bumping JNR to latest. I
didn't review that change, but I am not casting aspersions on those
who reviewed and merged it either. It is a particularly easy mistake
to make. But the fact is, I think we are unlikely to roll it back now.
So whether we like it or not, ASM 9 as a core dependency seems like it
is here to stay.

And since it is here to stay, and since compatibility is taken
seriously in recent versions of ASM, I think it is OK for plugins to
use the version from core by excluding the ASM dependency.

Basil

[1] 
https://web.archive.org/web/20120701173200/http://weblogs.java.net/blog/kohsuke/archive/2010/02/12/asm-incompatible-changes
[2] 
https://gitlab.ow2.org/asm/asm/-/commit/6a0e7842de436225f3866d3567834c6285107114

-- 
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/CAFwNDjpBuUqLfb7McWCZ6Ue2eMCGDj2vff9atO0_94VLykXCeQ%40mail.gmail.com.

Re: ASM in core

[Basil Crow]

On Fri, Jun 11, 2021 at 3:45 AM Ullrich Hafner  wrote:
>
> Wouldn’t it be helpful if we would also suggest which option we prefer? 
> Otherwise every plugin author needs to rethink the same options again and 
> again.
>
> E.g., option 1 did break all my integration tests with the token macro plugin 
> since it does not bundle ASM anymore.

As James pointed out, shading isn't a valid option. When I wrote that
I must have been thinking about the shading in Remoting, which isn't a
plugin at all.

Between excluding the library and masking classes, I tend to prefer
excluding the library, as it is less complex than masking classes at
runtime and also results in a leaner plugin. However, it is also more
risky depending on the compatibility level of the library, as James
noted. If the version in core is binary incompatible with the version
your plugin needs, you could have problems. For example, in
Timestamper I depend on OWASP Java HTML Sanitizer, which depends on
Guava 23, which I am excluding because core already provides Guava 11.
But that is risky, because if OWASP Java HTML Sanitizer ever calls a
method not provided by Guava 11 things would break. It happens not to
do that, but the situation should make anybody nervous. (It should
also make anybody nervous that core runs Guice 4.0, which requires
Guava 16, against Guava 11.)

In contrast, JaCoCo and Artifact Manager on S3 are using
"maskClasses", which is more complex as it involves changing runtime
behavior. But on the other hand it does allow the plugin's version of
the library to be used rather than core's version. The developer
documentation for this option reads: "You must manually verify that
the masked classes are complete under the transitive closure of the
Java linker: for example, masking one package but not another from a
library bundled in core could make classes in the masked package
unresolvable. […] If you did not understand any part of this section,
do not use these options. Even if you did, think twice." All of this
complexity should make anybody nervous as well.

As you can see, neither of these are very good options, which is why
removing (or hiding) Guice/JNR (and therefore Guava/ASM) are such
important long-term projects. In the short term, I tend to choose
excluding the library because it seems simpler, but you may need to
choose "maskClasses" if you need the newer version of the library.

-- 
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/CAFwNDjqYjYgAV1m%3D71U0XnLQ%3DTMO%2BfYvmEgGc%3DgOVej_wf6rFA%40mail.gmail.com.

Re: ASM in core

[Jim Klimov]

On June 11, 2021 10:18:30 AM UTC, kuisathaverat  wrote:
>Robert, Which plugin are you talking about? Which version of the core
>is
>that plugin required as minimum? there is another topic opened a few
>weeks
>ago about deprecated plugins, a plugin should bump it core minimum
>required
>version and update its dependencies often, if not it is not possible to
>ensure the interoperability between plugins and with the core, to
>maintain
>10 years of backward compatibility is not a good idea and block the
>project
>to move forward.
>
>El vie, 11 jun 2021 a las 11:19, Robert Sandell
>()
>escribió:
>
>> Some historical context to know where we "old timers" are coming from
>:)
>> https://kohsuke.org/2012/03/03/potd-package-renamed-asm/
>>
>> There are several times where I've needed to shade asm in plugins
>because
>> of some transitive dependency. Las time I think it was a dependency
>on ASM7
>> that blew up for me and I had to repackage that dependency to not
>break
>> other plugins that depended on my plugin.
>> That's why me and James and others are very very wary of bumping the
>asm
>> dependencies, I think even more wary than for Guava, because there
>isn't
>> enough code coverage due to how the classpath is during unit testing.
>> I am not fully read up on the JNI situation so I can't comment on
>that
>> situation, but it sounds like a damned if we do, damned if we don't
>kind of
>> situation?
>>
>> /B
>>
>> On Friday, June 11, 2021 at 9:49:51 AM UTC+2 kuisat...@gmail.com
>wrote:
>>
>>> Hi,
>>>
>>> I would like to add an issue related to not bump the ASM library, I
>>> recently hit an issue with stapler (see
>>> https://groups.google.com/g/jenkinsci-dev/c/JppfFwqIrCU) and it is
>>> related to compile the plugin for JDK 11 only,
>>> new plugins use new libraries and more and more libraries use JDK 11
>>> nowadays for obvious reasons.
>>> So bump the ASM version is something completely necessary. Break
>thing is
>>> fine and more when those things are 10 years old stuff, in general,
>the
>>> Jenkins Core has a few forked libraries that are a pain to maintain
>>> updated, most of them are 10 yo pains. Thus, I think it is a matter
>of
>>> making a damage control of the plugins affected by the change and
>fix those
>>> that are still maintained or in use, Do we know which plugins are
>affected
>>> by the change on ASM?
>>>
>>> BTW the ASM/JNR/JNA update is part of the JEP-211
>>>
>
>>>  and JENKINS-40689 
>so
>>> stuff longtime ago exposed
>>> El jueves, 10 de junio de 2021 a las 21:58:38 UTC+2,
>m...@basilcrow.com
>>> escribió:
>>>
 On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb 
>wrote:
 >
 > It would be good to see a more recent report given we’re on
>version 9
 in core to see if anything has changed in recent versions

 Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the
 upgrade of JNR (and therefore the accidental upgrade of ASM) in
>2.274.
 Here are the differences between ASM 5.0.3 and ASM 9.1:



>https://diff.revapi.org/?groupId=org.ow2.asm=asm=5.0.3=9.1


>https://diff.revapi.org/?groupId=org.ow2.asm=asm-analysis=5.0.3=9.1


>https://diff.revapi.org/?groupId=org.ow2.asm=asm-commons=5.0.3=9.1


>https://diff.revapi.org/?groupId=org.ow2.asm=asm-tree=5.0.3=9.1


>https://diff.revapi.org/?groupId=org.ow2.asm=asm-util=5.0.3=9.1

 The library seems quite stable between 5.0.3 and 9.1. Apart from
>new
 classes and the addition of generics, nothing seems to have been
 removed or renamed. (Similarly, recent versions of Guava are more
 stable than older versions.)

 In any case, I doubt we would roll back the JNR changes made in
>2.274
 at this point. For better or for worse, ASM 9.1 is here to stay as
 part of the core API, so we might as well own it in the short term.
 (In the long term, removing or hiding Guice/JNR and therefore
 Guava/ASM would be nice, of course.)

>>> --
>> 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/NhV_o6zxbzw/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/9c2d0cbb-2972-4e88-a51b-c53a5f39f5e4n%40googlegroups.com
>>
>
>> .
>>

One plugin that I can't locally `mvn package`, not even from its master branch, 
for several weeks now is github-branch-source-plugin

It complains about
  enforcer.RequireUpperBoundDeps
and lists 

Re: How to create a pre-release testing environment ?

[Goyot, Martin]

Thanks for your input. That's what I thought.

--

[image: Martin Goyot]

[image: Logo Tuleap]

Martin Goyot

+33.7.66.39.17.39

Consultant and Tuleap trainer

Enalean SAS - Tuleap

[image: Linkedin Tuleap]  [image:
Tuleap website]  [image: Twitter Tuleap]

[image: Bannière téléchargement ebook Agilité à l'échelle]



Le ven. 11 juin 2021 à 15:37, Ullrich Hafner  a
écrit :

> You get either all or nothing. There is no way to use filters for the
> experimental update center (as far as I know).
>
> I’m testing my plugins by simply copying the HPI (or JPI) files to a
> docker based Jenkins installation. All other plugins are the latest stable
> ones, just my plugins are the SNAPSHOT versions.
>
> Am 11.06.2021 um 14:24 schrieb Goyot, Martin :
>
> Hi there,
>
> I've seen
> https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/
> but I'm not sure it answers completely my need.
>
> I would like to be able to test my plugins before releasing them. In order
> to do so, and relying on the experimental updates system, I'd like to know
> if it would be possible to activate those experimental updates but only for
> some of the plugins of the platform. The goal would be to have a platform
> with every plugins on the latest released version + my plugin in the
> experimental update version so I can functionally test it against the
> current state of Jenkins and its ecosystem. Is there a way to achieve that,
> or did I miss some documentation?
>
> Regards,
> Martin
>
> --
>
> [image: Martin Goyot]
>
> [image: Logo Tuleap]
>
> Martin Goyot
> +33.7.66.39.17.39
> Consultant and Tuleap trainer
> Enalean SAS - Tuleap
>
> [image: Linkedin Tuleap]  [image:
> Tuleap website]  [image: Twitter Tuleap]
> 
> [image: Bannière téléchargement ebook Agilité à l'échelle]
> 
>
> --
> 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/CA%2Bb6JB-bqB_%3DLCK_NA3Ejjgc7uU9ZN%2BoiNCAP4Dovic%2BVZh9Lw%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/8F90CC06-64BE-4162-806E-F4FF4E563543%40gmail.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/CA%2Bb6JB_YsmfuJeHRJsesbuz_tXAF-wPG%2B0arveiPke4S%2BWEy6w%40mail.gmail.com.

Re: How to create a pre-release testing environment ?

[Ullrich Hafner]

You get either all or nothing. There is no way to use filters for the 
experimental update center (as far as I know). 

I’m testing my plugins by simply copying the HPI (or JPI) files to a docker 
based Jenkins installation. All other plugins are the latest stable ones, just 
my plugins are the SNAPSHOT versions.

> Am 11.06.2021 um 14:24 schrieb Goyot, Martin :
> 
> Hi there,
> 
> I've seen 
> https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/
>  
> 
>  but I'm not sure it answers completely my need.
> 
> I would like to be able to test my plugins before releasing them. In order to 
> do so, and relying on the experimental updates system, I'd like to know if it 
> would be possible to activate those experimental updates but only for some of 
> the plugins of the platform. The goal would be to have a platform with every 
> plugins on the latest released version + my plugin in the experimental update 
> version so I can functionally test it against the current state of Jenkins 
> and its ecosystem. Is there a way to achieve that, or did I miss some 
> documentation?
> 
> Regards,
> Martin
> --
> 
> 
> 
> 
> 
>   
> Martin Goyot
> +33.7.66.39.17.39
> Consultant and Tuleap trainer
> Enalean SAS - Tuleap
>      
>  
> 
> 
> -- 
> 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/CA%2Bb6JB-bqB_%3DLCK_NA3Ejjgc7uU9ZN%2BoiNCAP4Dovic%2BVZh9Lw%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/8F90CC06-64BE-4162-806E-F4FF4E563543%40gmail.com.

How to create a pre-release testing environment ?

[Goyot, Martin]

Hi there,

I've seen
https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/
but I'm not sure it answers completely my need.

I would like to be able to test my plugins before releasing them. In order
to do so, and relying on the experimental updates system, I'd like to know
if it would be possible to activate those experimental updates but only for
some of the plugins of the platform. The goal would be to have a platform
with every plugins on the latest released version + my plugin in the
experimental update version so I can functionally test it against the
current state of Jenkins and its ecosystem. Is there a way to achieve that,
or did I miss some documentation?

Regards,
Martin

--

[image: Martin Goyot]

[image: Logo Tuleap]

Martin Goyot

+33.7.66.39.17.39

Consultant and Tuleap trainer

Enalean SAS - Tuleap

[image: Linkedin Tuleap]  [image:
Tuleap website]  [image: Twitter Tuleap]

[image: Bannière téléchargement ebook Agilité à l'échelle]


-- 
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/CA%2Bb6JB-bqB_%3DLCK_NA3Ejjgc7uU9ZN%2BoiNCAP4Dovic%2BVZh9Lw%40mail.gmail.com.

Re: ASM in core

[Ullrich Hafner]

> 
> In general, when a plugin depends on a library already provided by
> core, I have seen three approaches in the short term:
> 
> 1. Exclude the library on the plugin side (e.g. how Token Macro excludes ASM)
> 2. Mask the library's classes (e.g. how JaCoCo masks ASM classes)
> 3. Shade the library into the plugin
> 
> […]
> For this reason, I recommend that all plugins that use Guava or ASM
> follow one of the three approaches outlined above in the short term.
> This is the only guaranteed way for plugins to avoid Guava and ASM
> problems at present.

Thanks for clarifying these options! 

Wouldn’t it be helpful if we would also suggest which option we prefer? 
Otherwise every plugin author needs to rethink the same options again and 
again. 

E.g., option 1 did break all my integration tests with the token macro plugin 
since it does not bundle ASM anymore. 


 
 

-- 
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/3F15ED4D-5175-4713-8DE7-6B5E974F2C5D%40gmail.com.

Re: ASM in core

[kuisathaverat]

Robert, Which plugin are you talking about? Which version of the core is
that plugin required as minimum? there is another topic opened a few weeks
ago about deprecated plugins, a plugin should bump it core minimum required
version and update its dependencies often, if not it is not possible to
ensure the interoperability between plugins and with the core, to maintain
10 years of backward compatibility is not a good idea and block the project
to move forward.

El vie, 11 jun 2021 a las 11:19, Robert Sandell ()
escribió:

> Some historical context to know where we "old timers" are coming from :)
> https://kohsuke.org/2012/03/03/potd-package-renamed-asm/
>
> There are several times where I've needed to shade asm in plugins because
> of some transitive dependency. Las time I think it was a dependency on ASM7
> that blew up for me and I had to repackage that dependency to not break
> other plugins that depended on my plugin.
> That's why me and James and others are very very wary of bumping the asm
> dependencies, I think even more wary than for Guava, because there isn't
> enough code coverage due to how the classpath is during unit testing.
> I am not fully read up on the JNI situation so I can't comment on that
> situation, but it sounds like a damned if we do, damned if we don't kind of
> situation?
>
> /B
>
> On Friday, June 11, 2021 at 9:49:51 AM UTC+2 kuisat...@gmail.com wrote:
>
>> Hi,
>>
>> I would like to add an issue related to not bump the ASM library, I
>> recently hit an issue with stapler (see
>> https://groups.google.com/g/jenkinsci-dev/c/JppfFwqIrCU) and it is
>> related to compile the plugin for JDK 11 only,
>> new plugins use new libraries and more and more libraries use JDK 11
>> nowadays for obvious reasons.
>> So bump the ASM version is something completely necessary. Break thing is
>> fine and more when those things are 10 years old stuff, in general, the
>> Jenkins Core has a few forked libraries that are a pain to maintain
>> updated, most of them are 10 yo pains. Thus, I think it is a matter of
>> making a damage control of the plugins affected by the change and fix those
>> that are still maintained or in use, Do we know which plugins are affected
>> by the change on ASM?
>>
>> BTW the ASM/JNR/JNA update is part of the JEP-211
>> 
>>  and JENKINS-40689  so
>> stuff longtime ago exposed
>> El jueves, 10 de junio de 2021 a las 21:58:38 UTC+2, m...@basilcrow.com
>> escribió:
>>
>>> On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb  wrote:
>>> >
>>> > It would be good to see a more recent report given we’re on version 9
>>> in core to see if anything has changed in recent versions
>>>
>>> Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the
>>> upgrade of JNR (and therefore the accidental upgrade of ASM) in 2.274.
>>> Here are the differences between ASM 5.0.3 and ASM 9.1:
>>>
>>>
>>> https://diff.revapi.org/?groupId=org.ow2.asm=asm=5.0.3=9.1
>>>
>>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-analysis=5.0.3=9.1
>>>
>>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-commons=5.0.3=9.1
>>>
>>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-tree=5.0.3=9.1
>>>
>>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-util=5.0.3=9.1
>>>
>>> The library seems quite stable between 5.0.3 and 9.1. Apart from new
>>> classes and the addition of generics, nothing seems to have been
>>> removed or renamed. (Similarly, recent versions of Guava are more
>>> stable than older versions.)
>>>
>>> In any case, I doubt we would roll back the JNR changes made in 2.274
>>> at this point. For better or for worse, ASM 9.1 is here to stay as
>>> part of the core API, so we might as well own it in the short term.
>>> (In the long term, removing or hiding Guice/JNR and therefore
>>> Guava/ASM would be nice, of course.)
>>>
>> --
> 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/NhV_o6zxbzw/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/9c2d0cbb-2972-4e88-a51b-c53a5f39f5e4n%40googlegroups.com
> 
> .
>


-- 
Un Saludo
Iván Fernández Calvo
https://www.linkedin.com/in/iv%C3%A1n-fern%C3%A1ndez-calvo-21425033

-- 
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 

Re: ASM in core

[Robert Sandell]

Some historical context to know where we "old timers" are coming from :)
https://kohsuke.org/2012/03/03/potd-package-renamed-asm/

There are several times where I've needed to shade asm in plugins because 
of some transitive dependency. Las time I think it was a dependency on ASM7 
that blew up for me and I had to repackage that dependency to not break 
other plugins that depended on my plugin.
That's why me and James and others are very very wary of bumping the asm 
dependencies, I think even more wary than for Guava, because there isn't 
enough code coverage due to how the classpath is during unit testing.
I am not fully read up on the JNI situation so I can't comment on that 
situation, but it sounds like a damned if we do, damned if we don't kind of 
situation?

/B

On Friday, June 11, 2021 at 9:49:51 AM UTC+2 kuisat...@gmail.com wrote:

> Hi,
>
> I would like to add an issue related to not bump the ASM library, I 
> recently hit an issue with stapler (see 
> https://groups.google.com/g/jenkinsci-dev/c/JppfFwqIrCU) and it is 
> related to compile the plugin for JDK 11 only,
> new plugins use new libraries and more and more libraries use JDK 11 
> nowadays for obvious reasons. 
> So bump the ASM version is something completely necessary. Break thing is 
> fine and more when those things are 10 years old stuff, in general, the 
> Jenkins Core has a few forked libraries that are a pain to maintain 
> updated, most of them are 10 yo pains. Thus, I think it is a matter of 
> making a damage control of the plugins affected by the change and fix those 
> that are still maintained or in use, Do we know which plugins are affected 
> by the change on ASM?
>
> BTW the ASM/JNR/JNA update is part of the JEP-211 
> 
>  and JENKINS-40689  so 
> stuff longtime ago exposed
> El jueves, 10 de junio de 2021 a las 21:58:38 UTC+2, m...@basilcrow.com 
> escribió:
>
>> On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb  wrote: 
>> > 
>> > It would be good to see a more recent report given we’re on version 9 
>> in core to see if anything has changed in recent versions 
>>
>> Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the 
>> upgrade of JNR (and therefore the accidental upgrade of ASM) in 2.274. 
>> Here are the differences between ASM 5.0.3 and ASM 9.1: 
>>
>>
>> https://diff.revapi.org/?groupId=org.ow2.asm=asm=5.0.3=9.1
>>  
>>
>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-analysis=5.0.3=9.1
>>  
>>
>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-commons=5.0.3=9.1
>>  
>>
>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-tree=5.0.3=9.1
>>  
>>
>> https://diff.revapi.org/?groupId=org.ow2.asm=asm-util=5.0.3=9.1
>>  
>>
>> The library seems quite stable between 5.0.3 and 9.1. Apart from new 
>> classes and the addition of generics, nothing seems to have been 
>> removed or renamed. (Similarly, recent versions of Guava are more 
>> stable than older versions.) 
>>
>> In any case, I doubt we would roll back the JNR changes made in 2.274 
>> at this point. For better or for worse, ASM 9.1 is here to stay as 
>> part of the core API, so we might as well own it in the short term. 
>> (In the long term, removing or hiding Guice/JNR and therefore 
>> Guava/ASM would be nice, of course.) 
>>
>

-- 
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/9c2d0cbb-2972-4e88-a51b-c53a5f39f5e4n%40googlegroups.com.

Re: ASM in core

[Ivan Fernandez Calvo]

Hi,

I would like to add an issue related to not bump the ASM library, I 
recently hit an issue with stapler (see 
https://groups.google.com/g/jenkinsci-dev/c/JppfFwqIrCU) and it is related 
to compile the plugin for JDK 11 only,
new plugins use new libraries and more and more libraries use JDK 11 
nowadays for obvious reasons. 
So bump the ASM version is something completely necessary. Break thing is 
fine and more when those things are 10 years old stuff, in general, the 
Jenkins Core has a few forked libraries that are a pain to maintain 
updated, most of them are 10 yo pains. Thus, I think it is a matter of 
making a damage control of the plugins affected by the change and fix those 
that are still maintained or in use, Do we know which plugins are affected 
by the change on ASM?

BTW the ASM/JNR/JNA update is part of the JEP-211 

 and JENKINS-40689  so 
stuff longtime ago exposed
El jueves, 10 de junio de 2021 a las 21:58:38 UTC+2, m...@basilcrow.com 
escribió:

> On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb  wrote:
> >
> > It would be good to see a more recent report given we’re on version 9 in 
> core to see if anything has changed in recent versions
>
> Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the
> upgrade of JNR (and therefore the accidental upgrade of ASM) in 2.274.
> Here are the differences between ASM 5.0.3 and ASM 9.1:
>
>
> https://diff.revapi.org/?groupId=org.ow2.asm=asm=5.0.3=9.1
>
> https://diff.revapi.org/?groupId=org.ow2.asm=asm-analysis=5.0.3=9.1
>
> https://diff.revapi.org/?groupId=org.ow2.asm=asm-commons=5.0.3=9.1
>
> https://diff.revapi.org/?groupId=org.ow2.asm=asm-tree=5.0.3=9.1
>
> https://diff.revapi.org/?groupId=org.ow2.asm=asm-util=5.0.3=9.1
>
> The library seems quite stable between 5.0.3 and 9.1. Apart from new
> classes and the addition of generics, nothing seems to have been
> removed or renamed. (Similarly, recent versions of Guava are more
> stable than older versions.)
>
> In any case, I doubt we would roll back the JNR changes made in 2.274
> at this point. For better or for worse, ASM 9.1 is here to stay as
> part of the core API, so we might as well own it in the short term.
> (In the long term, removing or hiding Guice/JNR and therefore
> Guava/ASM would be nice, of course.)
>

-- 
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/acdeb1a2-a126-45f8-bc4d-9e387fc05750n%40googlegroups.com.