date:20200225

Re: LTS baseline selection

2020-02-25 Thread Daniel Beck




> On 25. Feb 2020, at 16:44, Oleg Nenashev  wrote:
> 
> There is also  https://issues.jenkins-ci.org/browse/JENKINS-60409 which needs 
> to be investigated for the new LTS candidate. Looks like the default Jetty 
> behavior changed, and it may impact some users when they upgrade to the new 
> baseline

Irrelevant for this thread, as that issue affects every weekly release newer 
than the current LTS baseline. Might need upgrade docs or an expedited fix + 
back port but that applies to every potential LTS baseline choice.

-- 
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/7E8CB82D-2A1F-4A02-B42A-2AE0920CD822%40beckweb.net.

Re: LTS baseline selection

2020-02-25 Thread Oleg Nenashev

There is also  https://issues.jenkins-ci.org/browse/JENKINS-60409 which
needs to be investigated for the new LTS candidate. Looks like the default
Jetty behavior changed, and it may impact some users when they upgrade to
the new baseline


On Tue, Feb 25, 2020 at 3:23 PM Tim Jacomb  wrote:

> That looks like a fairly minor css tweak to fix that, is it just the
> search input? I wouldn’t exclude it from LTS for that issue
>
> On Tue, 25 Feb 2020 at 13:52, Ullrich Hafner 
> wrote:
>
>> While I like the new look, a mix of the new UI and the existing material
>> theme looks kind of weird now, even with disabled UI flag. There are a lot
>> of changes that are not part of the flag:
>>
>> Jenkins 2.222 (new UI disabled):
>>
>>
>>
>> Jenkins LTS:
>>
>>
>>
>>
>> Am 25.02.2020 um 14:39 schrieb Oleg Nenashev :
>>
>> Hi Ulli,
>>
>> The new frontend styling is behind the feature flag. By default there is
>> only a change in the Jenkins header which should not impact the plugin
>> developers except few ones who extend breadcrumbs or customize login/search
>> controls. I believe that only few plugin maintainers would be affected
>> there. Theme developers are a different story, and indeed there is likely
>> to be an impact on them. AFAIK Felix did some experiments with Material
>> Design Themes tho, and they worked pretty well out-of-the-box
>>
>> BR, Oleg
>>
>>
>>
>> On Tuesday, February 25, 2020 at 2:29:42 PM UTC+1, Ullrich Hafner wrote:
>>>
>>>
>>>-
>>>2.222 was released this Sunday, and the release metrics are yet to
>>>be seen.
>>>   - The community rating is 19 positives and 2 "I had to rollback"
>>>   - There is no issues reported to this release in Jira or in
>>>   social media
>>>   - There is one negative feedback in the UX SIG Gitter
>>>    about the header size in the
>>>   default UI. The header went from 68px to 96px (thanks Wadeck) and 
>>> caused
>>>   some feedback about mispositioned controls and impact on muscle memory
>>>   by Rocky Breslow. I consider it as an important feedback, but AFAICT 
>>> we can
>>>   optimize the header size and backport the change if needed
>>>
>>>
>>> I think we should give theme authors (and maybe plugin developers) more
>>> time to update their plugins to the new styling. Otherwise the new UI
>>> improvements might look like a step backward rather than a step forward.
>>> Then we also have the chance to provide some more UI enhancements in other
>>> areas so that the overall appearance looks consistent.
>>>
>>>
>>>
>> --
>> 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/2b66fcbd-3b15-4fea-8d39-9beeb11f5a8f%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/64C2E3C8-CA2D-4C36-BFAF-9889BA1EA634%40gmail.com
>> 
>> .
>>
> --
> 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/VRxRCP_IKhQ/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/CAH-3BieW76tV_2%3DqvwAJy7BpnaFzCZ6Mucoi7KGCY-JLefqABQ%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/CAPfivLDL24k1B_tCJ9wN6e%2Bx3EW_DeNdMVXA9mFCZuExB3KmCA%40mail.gmail.com.

Re: LTS baseline selection

2020-02-25 Thread Tim Jacomb

That looks like a fairly minor css tweak to fix that, is it just the search
input? I wouldn’t exclude it from LTS for that issue

On Tue, 25 Feb 2020 at 13:52, Ullrich Hafner 
wrote:

> While I like the new look, a mix of the new UI and the existing material
> theme looks kind of weird now, even with disabled UI flag. There are a lot
> of changes that are not part of the flag:
>
> Jenkins 2.222 (new UI disabled):
>
>
>
> Jenkins LTS:
>
>
>
>
> Am 25.02.2020 um 14:39 schrieb Oleg Nenashev :
>
> Hi Ulli,
>
> The new frontend styling is behind the feature flag. By default there is
> only a change in the Jenkins header which should not impact the plugin
> developers except few ones who extend breadcrumbs or customize login/search
> controls. I believe that only few plugin maintainers would be affected
> there. Theme developers are a different story, and indeed there is likely
> to be an impact on them. AFAIK Felix did some experiments with Material
> Design Themes tho, and they worked pretty well out-of-the-box
>
> BR, Oleg
>
>
>
> On Tuesday, February 25, 2020 at 2:29:42 PM UTC+1, Ullrich Hafner wrote:
>>
>>
>>-
>>2.222 was released this Sunday, and the release metrics are yet to be
>>seen.
>>   - The community rating is 19 positives and 2 "I had to rollback"
>>   - There is no issues reported to this release in Jira or in social
>>   media
>>   - There is one negative feedback in the UX SIG Gitter
>>    about the header size in the
>>   default UI. The header went from 68px to 96px (thanks Wadeck) and 
>> caused
>>   some feedback about mispositioned controls and impact on muscle memory
>>   by Rocky Breslow. I consider it as an important feedback, but AFAICT 
>> we can
>>   optimize the header size and backport the change if needed
>>
>>
>> I think we should give theme authors (and maybe plugin developers) more
>> time to update their plugins to the new styling. Otherwise the new UI
>> improvements might look like a step backward rather than a step forward.
>> Then we also have the chance to provide some more UI enhancements in other
>> areas so that the overall appearance looks consistent.
>>
>>
>>
> --
> 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/2b66fcbd-3b15-4fea-8d39-9beeb11f5a8f%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/64C2E3C8-CA2D-4C36-BFAF-9889BA1EA634%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/CAH-3BieW76tV_2%3DqvwAJy7BpnaFzCZ6Mucoi7KGCY-JLefqABQ%40mail.gmail.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Sladyn Nunes

As a potential applicant I did share one of the short drafts for the
proposal in the Jenkins developers group and would love to continue this
discussion on the meeting time proposed.
We could probably achieve a task list pre-GSOC if that is allowed in the
rules of GSOC that would give the potential participants a nice place to
start from.
Some of the tasks that we could achieve based on the discussion above that
could align our interests.
a)  Have a customizable jenkins builder where users could build their own
Jenkins distribution using very simple UI.
b) Have a set of ready-made distributions maintained by the respective
groups such as the AWS and have a centralized and easy to maintain
repository of such "Jenkins configurations".

On Tue, Feb 25, 2020 at 4:31 PM Rick  wrote:

> Sorry for the confusion. That’s my time slot. Not the meeting time. 2 or 4
> hours will kill everyone. I’ve updated it.
>
> https://doodle.com/poll/r748iar7gwusekrp
>
> Best,
> Rick
>
> On 02/25/2020 18:37，Oleg Nenashev
>  wrote：
>
> Would it be possible to limit the meeting time to 1 hour or so?
> Right now the invites are for 2 or 4 hours.
>
> BR, Oleg
>
>
> On Tue, Feb 25, 2020 at 11:25 AM Rick  wrote:
>
>>
>> Thanks for the proposal. I'd love to talk with all your guys. Below is
>> the Doodle link:
>> https://doodle.com/poll/r748iar7gwusekrp
>>
>> Best,
>> Rick
>> On 02/25/2020 18:11，Oleg Nenashev
>>  wrote：
>>
>> We could try to find an alternative time for the SIG meeting, I am happy
>> to run that. We can avoid using Google by running the meeting in Zoom.
>> It would be great if you could start a Doodle and list the slots possible
>> for you there.
>>
>> BR, Oleg
>>
>> On Tue, Feb 25, 2020 at 10:57 AM Rick  wrote:
>>
>>>
>>> Hi Oleg,
>>>
>>> I wish I could be a mentor of it. But the meeting time is too later for
>>> me. I’m not sure I can be there.
>>>
>>> Due to the network blocked issues, I cannot access the google.com about
>>> one month. I try to fix this.
>>>
>>> Best,
>>> Rick
>>> On 02/25/2020 17:48，Oleg Nenashev
>>>  wrote：
>>>
>>> Hi all,
>>>
>>> Some notes about this topic from the contributor summit in Brussels are
>>> available here:
>>> https://docs.google.com/document/d/1-OGpDPWkOdKw-e8C0v9hUGgQshCLmToodo0biwlejdk/edit#heading=h.wzuq89kuh5wy
>>> Maybe Chris or Tim could add more notes there as the most active
>>> participants, but I also believe that this project idea and the topics
>>> there are very well aligned. Thanks a lot to everyone who contributed to
>>> this discussion
>>>
>>> I wonder whether we could have a dedicated session for this project idea
>>> at one of the Platform SIG meetings
>>>  (noon UTC on Thursdays,
>>> next one will be on 27th).
>>>
>>>
>>> Best regards,
>>> Oleg
>>>
>>> P.S: We are looking for potential GSoC project mentors! If you are
>>> interested in mentoring this project idea, let the GSoC team know!
>>>
>>>
>>>
>>> On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León
>>> Jiménez wrote:

 Hi.

 I've been working on some ideas pretty similar to all you are
 suggesting here. The ultimate goal is, sort of:
 * Allow to have a Jenkins ready with all stuff in a single click or
 command. Or compared to IKEA: avoid having to mount the IKEA furniture
 manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka
 plugins) and people usually don't know what to use to get their furniture
 mounted :-)
 * Allow people to share "their Jenkins", meaning Jenkins version +
 plugins + sample-running jobs + configurations (but credentials) to allow
 community to reuse them. Some projects have contributed to allow that
 without too much effort, like JCasC, custom-war-packager, ...
 * Allow people to kind of vote for packages to be able to find out the
 most mature or relevant among all existing.
 * Have a centralized and easy to maintain repository of such "Jenkins
 configurations". It could be as easy as a GH repo with a certain template
 (readme + configuration file + assets), although some features like voting
 may be missed.

 Beyond the specific proposal I made I find there are a lot of people
 thinking on the same problem and slightly different solutions. So it would
 be great to align efforts on the same direction to extract the most from us
 to achieve something deliverable in a short time.

 Not sure under what umbrella we could do that, GSoC, JEP, ... though.

 Best regards.

 On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding 
 wrote:

> Jesse - cheers for pointing out the previous AWS packaging attempt, I
> will take a look.
>
> Re version pinning, if this can’t be done in the POM, are there any
> Jenkins tools which can do this, apart from the cloudbees assured update
> feed? (I’m thinking of how we could support users on Jenkins community
> edition.)
>

Re: LTS baseline selection

2020-02-25 Thread Ullrich Hafner

While I like the new look, a mix of the new UI and the existing material theme 
looks kind of weird now, even with disabled UI flag. There are a lot of changes 
that are not part of the flag:

Jenkins 2.222 (new UI disabled):



Jenkins LTS:




> Am 25.02.2020 um 14:39 schrieb Oleg Nenashev :
> 
> Hi Ulli,
> 
> The new frontend styling is behind the feature flag. By default there is only 
> a change in the Jenkins header which should not impact the plugin developers 
> except few ones who extend breadcrumbs or customize login/search controls. I 
> believe that only few plugin maintainers would be affected there. Theme 
> developers are a different story, and indeed there is likely to be an impact 
> on them. AFAIK Felix did some experiments with Material Design Themes tho, 
> and they worked pretty well out-of-the-box
> 
> BR, Oleg
> 
> 
> 
> On Tuesday, February 25, 2020 at 2:29:42 PM UTC+1, Ullrich Hafner wrote:
>> 
>> 2.222 was released this Sunday, and the release metrics are yet to be seen. 
>> The community rating is 19 positives and 2 "I had to rollback"
>> There is no issues reported to this release in Jira or in social media
>> There is one negative feedback in the UX SIG Gitter 
>>  about the header size in the default 
>> UI. The header went from 68px to 96px (thanks Wadeck) and caused some 
>> feedback about mispositioned controls and impact on muscle memory by Rocky 
>> Breslow. I consider it as an important feedback, but AFAICT we can optimize 
>> the header size and backport the change if needed
> 
> I think we should give theme authors (and maybe plugin developers) more time 
> to update their plugins to the new styling. Otherwise the new UI improvements 
> might look like a step backward rather than a step forward. Then we also have 
> the chance to provide some more UI enhancements in other areas so that the 
> overall appearance looks consistent.  
> 
> 
> 
> -- 
> 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/2b66fcbd-3b15-4fea-8d39-9beeb11f5a8f%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/64C2E3C8-CA2D-4C36-BFAF-9889BA1EA634%40gmail.com.

Re: LTS baseline selection

2020-02-25 Thread Oleg Nenashev

Hi Ulli,

The new frontend styling is behind the feature flag. By default there is 
only a change in the Jenkins header which should not impact the plugin 
developers except few ones who extend breadcrumbs or customize login/search 
controls. I believe that only few plugin maintainers would be affected 
there. Theme developers are a different story, and indeed there is likely 
to be an impact on them. AFAIK Felix did some experiments with Material 
Design Themes tho, and they worked pretty well out-of-the-box

BR, Oleg



On Tuesday, February 25, 2020 at 2:29:42 PM UTC+1, Ullrich Hafner wrote:
>
>
>- 
>2.222 was released this Sunday, and the release metrics are yet to be 
>seen. 
>   - The community rating is 19 positives and 2 "I had to rollback"
>   - There is no issues reported to this release in Jira or in social 
>   media
>   - There is one negative feedback in the UX SIG Gitter 
>    about the header size in the 
>   default UI. The header went from 68px to 96px (thanks Wadeck) and 
> caused 
>   some feedback about mispositioned controls and impact on muscle memory 
>   by Rocky Breslow. I consider it as an important feedback, but AFAICT we 
> can 
>   optimize the header size and backport the change if needed
>
>
> I think we should give theme authors (and maybe plugin developers) more 
> time to update their plugins to the new styling. Otherwise the new UI 
> improvements might look like a step backward rather than a step forward. 
> Then we also have the chance to provide some more UI enhancements in other 
> areas so that the overall appearance looks consistent.  
>
>
>

-- 
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/2b66fcbd-3b15-4fea-8d39-9beeb11f5a8f%40googlegroups.com.

Re: LTS baseline selection

2020-02-25 Thread Ullrich Hafner

> 
> 2.222 was released this Sunday, and the release metrics are yet to be seen. 
> The community rating is 19 positives and 2 "I had to rollback"
> There is no issues reported to this release in Jira or in social media
> There is one negative feedback in the UX SIG Gitter 
>  about the header size in the default UI. 
> The header went from 68px to 96px (thanks Wadeck) and caused some feedback 
> about mispositioned controls and impact on muscle memory by Rocky Breslow. I 
> consider it as an important feedback, but AFAICT we can optimize the header 
> size and backport the change if needed

I think we should give theme authors (and maybe plugin developers) more time to 
update their plugins to the new styling. Otherwise the new UI improvements 
might look like a step backward rather than a step forward. Then we also have 
the chance to provide some more UI enhancements in other areas so that the 
overall appearance looks consistent.  


-- 
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/D339AB58-0DF1-4848-9C0D-AEDAE695107F%40gmail.com.

Re: JAMS in meetup account disappearing

2020-02-25 Thread Oleg Nenashev

Hi Alexandru,

I am going to request org admin rights in all Jenkins Area meetups to work
on new organizers.
Regarding the Stockholm meetup, I know the previous organizers. So I will
follow-up in a private email.

Best regards,
Oleg


On Tue, Feb 25, 2020 at 1:22 PM Alexandru Chiritescu 
wrote:

> Hi, The Stockholm Jenkins Meetup group was restored, but none of the old
> admins are organisers in the group. We would like to organize an event
> soon. How can we proceed to be able to organize meetups again under this
> group? Also, will the group be rebranded to the wider context of CDF? While
> the group was deleted, we were hosted by another meetup group for an event (
> https://www.meetup.com/DevOps-Stockholm/events/268502971/), but we would
> like to resume using this group if possible. Thanks, Alex
>
> On Thursday, February 6, 2020 at 12:34:56 PM UTC+1, Oleg Nenashev wrote:
>>
>> Some updates in this thread:
>>
>>- Last week we had a discussion with Jacqueline Salinas at FOSDEM,
>>and she escalated the meetups recovery topic to meetup.com (again)
>>- Around 20 meetups were restored after that. IIUC it represents all
>>meetup groups which have ever hosted a Jenkins meetup
>>- We updated all the documentation for mailing lists to redirect them
>>to Advocacy INFRA tickets have been created for archiving old
>>channels, but it will take a while due to other higher priorities in the
>>INFRA team
>>
>> So now we can iterate on contacting these meetup groups and exploring
>> options to recover regular Jenkins or CI/CD meetups there. If you are a
>> leader of any restored meetup groups, please consider scheduling something
>>
>> Best regards,
>> Oleg
>>
>> On Thursday, January 16, 2020 at 6:25:40 AM UTC-5, Oleg Nenashev wrote:
>>>
>>> Just a quick update here, yesterday both topics were approved by the
>>> Governance board:
>>>
>>>- Approve the suggested process in general && delegate the final
>>>process decision to the event officer and Advocacy and Outreach SIG
>>>(immediate/short-term stepdown for meetups which never happened, grace
>>>period for stale ones)
>>>- Approve archiving of jenkinsci-jam and events mailing lists
>>>mailing lists in favor of Advocacy & Outreach channels
>>>
>>> We will proceed at Advocacy SIG meeting on 16th
>>> 
>>>  with
>>> these topics
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Wednesday, January 15, 2020 at 11:02:09 AM UTC+1, ogondza wrote:

 +1 from me on doing the cleanup. Meetup groups come and go. Great to
 see
 a documented way to gring them back to life.

 On 14/01/2020 14.59, Oleg Nenashev wrote:
 > Thanks a lot for the notice Alyssa!
 >
 > If my message is too long, *TL;DR: *the meetups will be restored, but
 it
 > is time to clean up the inactive meetups. There is a proposal below
 >
 > Some updates there:
 >
 >   * As communicated by Tracy, the root cause is that meetup.com
 support
 > removed more meetups than it was requested by CDF.
 >   * Last week we had a meeting with CDF where we discussed the issue.
 > Participants: Alyssa Tong (Jenkins Event Officer), Jacqueline
 > Salinas (Director of Ecosystem, CDF), Tracy Miranda and me
 >   * At this meeting we agreed that:
 >   o Removed meetups meetups will be restored. It will take a
 while
 > since it is a lengthy manual process by meetup.com support
 >   o CDF will grant us an additional grace 3-month grace period to
 > try restoring inactive meetups in the Jenkins community
 (and/or
 > to convert them to CI/CD meetups). Heads-up about cleaning up
 > inactive meetups was sent out on *Oct 26* to meetup
 organizers,
 > so we will need to reimplement the process and do additional
 > communications
 >   o If meetups are not restored, CDF will use the "step down"
 > process
 > <
 https://help.meetup.com/hc/en-us/articles/360002882191-Stepping-down-as-the-organizer-of-a-group>

 > instead of deleting the meetups. It will give the local
 > communities an additional chance to restore the meetups
 >
 > Just to explain the reasons of the Jenkins Area Meetups cleanup:
 >
 >   * Running CI/CD Pro Meetup.com account
 >  costs *12k USD per
 quarter*.
 > The majority of these costs used to go to *106 *Jenkins Area
 Meetups
 >   * CDF has a limited budget for Outreach programs and meetups. They
 are
 > happy to sponsor active meetups, but in the case of Jenkins we
 > accumulated a number of inactive ones
 >   * Meanwhile, more than 60% of the meetups are dormant. Inactive
 > meetups cost the same amount

Re: JAMS in meetup account disappearing

2020-02-25 Thread Alexandru Chiritescu

Hi, The Stockholm Jenkins Meetup group was restored, but none of the old 
admins are organisers in the group. We would like to organize an event 
soon. How can we proceed to be able to organize meetups again under this 
group? Also, will the group be rebranded to the wider context of CDF? While 
the group was deleted, we were hosted by another meetup group for an event (
https://www.meetup.com/DevOps-Stockholm/events/268502971/), but we would 
like to resume using this group if possible. Thanks, Alex

On Thursday, February 6, 2020 at 12:34:56 PM UTC+1, Oleg Nenashev wrote:
>
> Some updates in this thread:
>
>- Last week we had a discussion with Jacqueline Salinas at FOSDEM, and 
>she escalated the meetups recovery topic to meetup.com (again)
>- Around 20 meetups were restored after that. IIUC it represents all 
>meetup groups which have ever hosted a Jenkins meetup 
>- We updated all the documentation for mailing lists to redirect them 
>to Advocacy INFRA tickets have been created for archiving old 
>channels, but it will take a while due to other higher priorities in the 
>INFRA team
>
> So now we can iterate on contacting these meetup groups and exploring 
> options to recover regular Jenkins or CI/CD meetups there. If you are a 
> leader of any restored meetup groups, please consider scheduling something
>
> Best regards,
> Oleg
>
> On Thursday, January 16, 2020 at 6:25:40 AM UTC-5, Oleg Nenashev wrote:
>>
>> Just a quick update here, yesterday both topics were approved by the 
>> Governance board:
>>
>>- Approve the suggested process in general && delegate the final 
>>process decision to the event officer and Advocacy and Outreach SIG 
>>(immediate/short-term stepdown for meetups which never happened, grace 
>>period for stale ones)
>>- Approve archiving of jenkinsci-jam and events mailing lists mailing 
>>lists in favor of Advocacy & Outreach channels
>>
>> We will proceed at Advocacy SIG meeting on 16th 
>> 
>>  with 
>> these topics
>>
>> Best regards,
>> Oleg
>>
>> On Wednesday, January 15, 2020 at 11:02:09 AM UTC+1, ogondza wrote:
>>>
>>> +1 from me on doing the cleanup. Meetup groups come and go. Great to see 
>>> a documented way to gring them back to life. 
>>>
>>> On 14/01/2020 14.59, Oleg Nenashev wrote: 
>>> > Thanks a lot for the notice Alyssa! 
>>> > 
>>> > If my message is too long, *TL;DR: *the meetups will be restored, but 
>>> it 
>>> > is time to clean up the inactive meetups. There is a proposal below 
>>> > 
>>> > Some updates there: 
>>> > 
>>> >   * As communicated by Tracy, the root cause is that meetup.com 
>>> support 
>>> > removed more meetups than it was requested by CDF. 
>>> >   * Last week we had a meeting with CDF where we discussed the issue. 
>>> > Participants: Alyssa Tong (Jenkins Event Officer), Jacqueline 
>>> > Salinas (Director of Ecosystem, CDF), Tracy Miranda and me 
>>> >   * At this meeting we agreed that: 
>>> >   o Removed meetups meetups will be restored. It will take a while 
>>> > since it is a lengthy manual process by meetup.com support 
>>> >   o CDF will grant us an additional grace 3-month grace period to 
>>> > try restoring inactive meetups in the Jenkins community 
>>> (and/or 
>>> > to convert them to CI/CD meetups). Heads-up about cleaning up 
>>> > inactive meetups was sent out on *Oct 26* to meetup 
>>> organizers, 
>>> > so we will need to reimplement the process and do additional 
>>> > communications 
>>> >   o If meetups are not restored, CDF will use the "step down" 
>>> > process 
>>> > <
>>> https://help.meetup.com/hc/en-us/articles/360002882191-Stepping-down-as-the-organizer-of-a-group>
>>>  
>>>
>>> > instead of deleting the meetups. It will give the local 
>>> > communities an additional chance to restore the meetups 
>>> > 
>>> > Just to explain the reasons of the Jenkins Area Meetups cleanup: 
>>> > 
>>> >   * Running CI/CD Pro Meetup.com account 
>>> >  costs *12k USD per 
>>> quarter*. 
>>> > The majority of these costs used to go to *106 *Jenkins Area 
>>> Meetups 
>>> >   * CDF has a limited budget for Outreach programs and meetups. They 
>>> are 
>>> > happy to sponsor active meetups, but in the case of Jenkins we 
>>> > accumulated a number of inactive ones 
>>> >   * Meanwhile, more than 60% of the meetups are dormant. Inactive 
>>> > meetups cost the same amount of money as active ones 
>>> >   o *27* JAMs groups have NEVER had a meetup on meetup.com 
>>> >   o *40* other JAMs did not have any events organized in 2019 
>>> >   * Dormant JAMs prevent CDF from... 
>>> >   o Sponsoring swag/food/venue for meetups and other events 
>>> >   o Onboarding new CI/CD and Jenkins meetups in

Re: LTS baseline selection

2020-02-25 Thread Oleg Nenashev

Regarding 2.222... I believe there is a lot for interest to get 2.222 in 
the LTS so that plugins could start adapting to the new Systemread and 
Manage permissions earlier. There is a lot of experimental features and new 
APIs included there, and I believe it would be valuable for the Jenkins 
community if this release was selected as an LTS baseline. At the same 
time, I admit that the release has not been battle tested for long.

Some notes:

   - 2.222 was released this Sunday, and the release metrics are yet to be 
   seen. 
  - The community rating is 19 positives and 2 "I had to rollback"
  - There is no issues reported to this release in Jira or in social 
  media
  - There is one negative feedback in the UX SIG Gitter 
   about the header size in the 
  default UI. The header went from 68px to 96px (thanks Wadeck) and caused 
  some feedback about mispositioned controls and impact on muscle memory 
  by Rocky Breslow. I consider it as an important feedback, but AFAICT we 
can 
  optimize the header size and backport the change if needed
   - 2.221 has a flawless community rating (31 positive), there is no 
   regressions reported
  - JENKINS-61121  will 
  need to be backported if we chose this release
  - Issues in both releases
  - There is a JENKINS-61197 
   regression which 
  impacts custom workspaces in the root directory (or Windows drive label). 
I 
  am working on a fix, it should be backportable
   
My personal preference would be to go with 2.222 unless there are major 
issues discovered there by the RC date. In order to make it happen, we 
should at least process the UX report with the header. I deployed 2.222 on 
my local setup, and it looks good with the default setting and with Manage 
and SystemRead permissions enabled. Experimental Web UI works as well, but 
I reverted to the classic one. 

BR, Oleg


On Tuesday, February 25, 2020 at 11:39:35 AM UTC+1, Baptiste Mathus wrote:
>
>
>
> On Tue, Feb 25, 2020 at 12:33 AM Jesse Glick  > wrote:
>
>> On Mon, Feb 24, 2020 at 4:37 PM Oliver Gondža > > wrote:
>> > the baseline candidates
>>
>> Reference: https://jenkins.io/changelog/
>>
>> > in advance to speed up the discussion in governance meeting.
>>
>> Are baselines still selected during governance meetings? I thought
>> that had switched to the list.
>>
>
> I *think* the discussion happens here a lot, but the final /stamp/ after 
> the trend/discussion/decision here is still done during gov meeting (still 
> makes sense IMO).
>
>
>
>> -- 
>> 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 jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1C4wg1EiT18OuyG3Mi3WeZspgwtUuqpME2L_7P-O%2B_CQ%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/a98cbee5-e2b9-4164-be01-7f7c5c2ddbfe%40googlegroups.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Rick

Sorry for the confusion. That’s my time slot. Not the meeting time. 2 or 4
hours will kill everyone. I’ve updated it.

https://doodle.com/poll/r748iar7gwusekrp

Best,
Rick

On 02/25/2020 18:37，Oleg Nenashev wrote：
Would it be possible to limit the meeting time to 1 hour or so?
Right now the invites are for 2 or 4 hours.

BR, Oleg

On Tue, Feb 25, 2020 at 11:25 AM Rick wrote:

Thanks for the proposal. I'd love to talk with all your guys. Below is the
Doodle link:
https://doodle.com/poll/r748iar7gwusekrp

Best,
Rick
On 02/25/2020 18:11，Oleg Nenashev wrote：
We could try to find an alternative time for the SIG meeting, I am happy to run
that. We can avoid using Google by running the meeting in Zoom.
It would be great if you could start a Doodle and list the slots possible for
you there.

BR, Oleg

On Tue, Feb 25, 2020 at 10:57 AM Rick wrote:

Hi Oleg,

I wish I could be a mentor of it. But the meeting time is too later for me. I’m
not sure I can be there.

Due to the network blocked issues, I cannot access the google.com about one
month. I try to fix this.

Best,
Rick
On 02/25/2020 17:48，Oleg Nenashev wrote：
Hi all,

Some notes about this topic from the contributor summit in Brussels are
available here:
https://docs.google.com/document/d/1-OGpDPWkOdKw-e8C0v9hUGgQshCLmToodo0biwlejdk/edit#heading=h.wzuq89kuh5wy
Maybe Chris or Tim could add more notes there as the most active participants,
but I also believe that this project idea and the topics there are very well
aligned. Thanks a lot to everyone who contributed to this discussion

I wonder whether we could have a dedicated session for this project idea at one
of the Platform SIG meetings (noon UTC on Thursdays, next one will be on 27th).

Best regards,
Oleg

P.S: We are looking for potential GSoC project mentors! If you are interested
in mentoring this project idea, let the GSoC team know!

On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León Jiménez
wrote:
Hi.

I've been working on some ideas pretty similar to all you are suggesting here.
The ultimate goal is, sort of:
* Allow to have a Jenkins ready with all stuff in a single click or command. Or
compared to IKEA: avoid having to mount the IKEA furniture manually because
unlike IKEA, we have dozens of Shrönghon screw (aka plugins) and people usually
don't know what to use to get their furniture mounted :-)
* Allow people to share "their Jenkins", meaning Jenkins version + plugins +
sample-running jobs + configurations (but credentials) to allow community to
reuse them. Some projects have contributed to allow that without too much
effort, like JCasC, custom-war-packager, ...
* Allow people to kind of vote for packages to be able to find out the most
mature or relevant among all existing.
* Have a centralized and easy to maintain repository of such "Jenkins
configurations". It could be as easy as a GH repo with a certain template
(readme + configuration file + assets), although some features like voting may
be missed.

Beyond the specific proposal I made I find there are a lot of people thinking
on the same problem and slightly different solutions. So it would be great to
align efforts on the same direction to extract the most from us to achieve
something deliverable in a short time.

Not sure under what umbrella we could do that, GSoC, JEP, ... though.

Best regards.

On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding wrote:

Jesse - cheers for pointing out the previous AWS packaging attempt, I will take
a look.

Re version pinning, if this can’t be done in the POM, are there any Jenkins
tools which can do this, apart from the cloudbees assured update feed? (I’m
thinking of how we could support users on Jenkins community edition.)

Re what gets included - we could insist that any plugins included in a cloud
vendor metapackage meet certain criteria, so that they can play together better:
- They must be able to no-op if the user doesn’t need them (ie their default is
to quietly sit on the Jenkins server and not do anything, until the user
configures them).
- They must all use the same cloud provider SDK artifact (probably the Jenkins
re-packaged HPI version of the SDK).
- If appropriate, they must all take their baseline configuration from the same
cloud provider ‘global config’ plugin.

Re pre-defined packages - I would certainly like to see the cloud vendors get
more involved with supporting their respective Jenkins plugins.

Chris

--
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 jenkin...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.com.

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

Re: LTS baseline selection

2020-02-25 Thread Baptiste Mathus

On Tue, Feb 25, 2020 at 12:33 AM Jesse Glick  wrote:

> On Mon, Feb 24, 2020 at 4:37 PM Oliver Gondža  wrote:
> > the baseline candidates
>
> Reference: https://jenkins.io/changelog/
>
> > in advance to speed up the discussion in governance meeting.
>
> Are baselines still selected during governance meetings? I thought
> that had switched to the list.
>

I *think* the discussion happens here a lot, but the final /stamp/ after
the trend/discussion/decision here is still done during gov meeting (still
makes sense IMO).



> --
> 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/CANfRfr1C4wg1EiT18OuyG3Mi3WeZspgwtUuqpME2L_7P-O%2B_CQ%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/CAPyTVp3jDBk-QahuuwhkVbLK_9BJSJRMNq7ZFBNX5qp7T1LcFw%40mail.gmail.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Oleg Nenashev

Would it be possible to limit the meeting time to 1 hour or so?
Right now the invites are for 2 or 4 hours.

BR, Oleg


On Tue, Feb 25, 2020 at 11:25 AM Rick  wrote:

>
> Thanks for the proposal. I'd love to talk with all your guys. Below is the
> Doodle link:
> https://doodle.com/poll/r748iar7gwusekrp
>
> Best,
> Rick
> On 02/25/2020 18:11，Oleg Nenashev
>  wrote：
>
> We could try to find an alternative time for the SIG meeting, I am happy
> to run that. We can avoid using Google by running the meeting in Zoom.
> It would be great if you could start a Doodle and list the slots possible
> for you there.
>
> BR, Oleg
>
> On Tue, Feb 25, 2020 at 10:57 AM Rick  wrote:
>
>>
>> Hi Oleg,
>>
>> I wish I could be a mentor of it. But the meeting time is too later for
>> me. I’m not sure I can be there.
>>
>> Due to the network blocked issues, I cannot access the google.com about
>> one month. I try to fix this.
>>
>> Best,
>> Rick
>> On 02/25/2020 17:48，Oleg Nenashev
>>  wrote：
>>
>> Hi all,
>>
>> Some notes about this topic from the contributor summit in Brussels are
>> available here:
>> https://docs.google.com/document/d/1-OGpDPWkOdKw-e8C0v9hUGgQshCLmToodo0biwlejdk/edit#heading=h.wzuq89kuh5wy
>> Maybe Chris or Tim could add more notes there as the most active
>> participants, but I also believe that this project idea and the topics
>> there are very well aligned. Thanks a lot to everyone who contributed to
>> this discussion
>>
>> I wonder whether we could have a dedicated session for this project idea
>> at one of the Platform SIG meetings
>>  (noon UTC on Thursdays,
>> next one will be on 27th).
>>
>>
>> Best regards,
>> Oleg
>>
>> P.S: We are looking for potential GSoC project mentors! If you are
>> interested in mentoring this project idea, let the GSoC team know!
>>
>>
>>
>> On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León
>> Jiménez wrote:
>>>
>>> Hi.
>>>
>>> I've been working on some ideas pretty similar to all you are suggesting
>>> here. The ultimate goal is, sort of:
>>> * Allow to have a Jenkins ready with all stuff in a single click or
>>> command. Or compared to IKEA: avoid having to mount the IKEA furniture
>>> manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka
>>> plugins) and people usually don't know what to use to get their furniture
>>> mounted :-)
>>> * Allow people to share "their Jenkins", meaning Jenkins version +
>>> plugins + sample-running jobs + configurations (but credentials) to allow
>>> community to reuse them. Some projects have contributed to allow that
>>> without too much effort, like JCasC, custom-war-packager, ...
>>> * Allow people to kind of vote for packages to be able to find out the
>>> most mature or relevant among all existing.
>>> * Have a centralized and easy to maintain repository of such "Jenkins
>>> configurations". It could be as easy as a GH repo with a certain template
>>> (readme + configuration file + assets), although some features like voting
>>> may be missed.
>>>
>>> Beyond the specific proposal I made I find there are a lot of people
>>> thinking on the same problem and slightly different solutions. So it would
>>> be great to align efforts on the same direction to extract the most from us
>>> to achieve something deliverable in a short time.
>>>
>>> Not sure under what umbrella we could do that, GSoC, JEP, ... though.
>>>
>>> Best regards.
>>>
>>> On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding 
>>> wrote:
>>>
 Jesse - cheers for pointing out the previous AWS packaging attempt, I
 will take a look.

 Re version pinning, if this can’t be done in the POM, are there any
 Jenkins tools which can do this, apart from the cloudbees assured update
 feed? (I’m thinking of how we could support users on Jenkins community
 edition.)

 Re what gets included - we could insist that any plugins included in a
 cloud vendor metapackage meet certain criteria, so that they can play
 together better:
 - They must be able to no-op if the user doesn’t need them (ie their
 default is to quietly sit on the Jenkins server and not do anything, until
 the user configures them).
 - They must all use the same cloud provider SDK artifact (probably the
 Jenkins re-packaged HPI version of the SDK).
 - If appropriate, they must all take their baseline configuration from
 the same cloud provider ‘global config’ plugin.

 Re pre-defined packages - I would certainly like to see the cloud
 vendors get more involved with supporting their respective Jenkins plugins.

 Chris

 --
 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 jenkin...@googlegroups.com.
 To view this discussion on the web visit

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Rick

Thanks for the proposal. I'd love to talk with all your guys. Below is the
Doodle link:
https://doodle.com/poll/r748iar7gwusekrp

BR, Oleg

On Tue, Feb 25, 2020 at 10:57 AM Rick wrote:

Hi Oleg,

I wish I could be a mentor of it. But the meeting time is too later for me. I’m
not sure I can be there.

Due to the network blocked issues, I cannot access the google.com about one
month. I try to fix this.

Best,
Rick
On 02/25/2020 17:48，Oleg Nenashev wrote：
Hi all,

I wonder whether we could have a dedicated session for this project idea at one
of the Platform SIG meetings (noon UTC on Thursdays, next one will be on 27th).

Best regards,
Oleg

P.S: We are looking for potential GSoC project mentors! If you are interested
in mentoring this project idea, let the GSoC team know!

On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León Jiménez
wrote:
Hi.

Not sure under what umbrella we could do that, GSoC, JEP, ... though.

Best regards.

On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding wrote:

Jesse - cheers for pointing out the previous AWS packaging attempt, I will take
a look.

Re pre-defined packages - I would certainly like to see the cloud vendors get
more involved with supporting their respective Jenkins plugins.

Chris

--
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/3b8b4036-9774-40eb-ac99-42ce54a2b6a0%40googlegroups.com.

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

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Oleg Nenashev

We could try to find an alternative time for the SIG meeting, I am happy to
run that. We can avoid using Google by running the meeting in Zoom.
It would be great if you could start a Doodle and list the slots possible
for you there.

BR, Oleg

On Tue, Feb 25, 2020 at 10:57 AM Rick  wrote:

>
> Hi Oleg,
>
> I wish I could be a mentor of it. But the meeting time is too later for
> me. I’m not sure I can be there.
>
> Due to the network blocked issues, I cannot access the google.com about
> one month. I try to fix this.
>
> Best,
> Rick
> On 02/25/2020 17:48，Oleg Nenashev
>  wrote：
>
> Hi all,
>
> Some notes about this topic from the contributor summit in Brussels are
> available here:
> https://docs.google.com/document/d/1-OGpDPWkOdKw-e8C0v9hUGgQshCLmToodo0biwlejdk/edit#heading=h.wzuq89kuh5wy
> Maybe Chris or Tim could add more notes there as the most active
> participants, but I also believe that this project idea and the topics
> there are very well aligned. Thanks a lot to everyone who contributed to
> this discussion
>
> I wonder whether we could have a dedicated session for this project idea
> at one of the Platform SIG meetings
>  (noon UTC on Thursdays, next
> one will be on 27th).
>
>
> Best regards,
> Oleg
>
> P.S: We are looking for potential GSoC project mentors! If you are
> interested in mentoring this project idea, let the GSoC team know!
>
>
>
> On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León
> Jiménez wrote:
>>
>> Hi.
>>
>> I've been working on some ideas pretty similar to all you are suggesting
>> here. The ultimate goal is, sort of:
>> * Allow to have a Jenkins ready with all stuff in a single click or
>> command. Or compared to IKEA: avoid having to mount the IKEA furniture
>> manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka
>> plugins) and people usually don't know what to use to get their furniture
>> mounted :-)
>> * Allow people to share "their Jenkins", meaning Jenkins version +
>> plugins + sample-running jobs + configurations (but credentials) to allow
>> community to reuse them. Some projects have contributed to allow that
>> without too much effort, like JCasC, custom-war-packager, ...
>> * Allow people to kind of vote for packages to be able to find out the
>> most mature or relevant among all existing.
>> * Have a centralized and easy to maintain repository of such "Jenkins
>> configurations". It could be as easy as a GH repo with a certain template
>> (readme + configuration file + assets), although some features like voting
>> may be missed.
>>
>> Beyond the specific proposal I made I find there are a lot of people
>> thinking on the same problem and slightly different solutions. So it would
>> be great to align efforts on the same direction to extract the most from us
>> to achieve something deliverable in a short time.
>>
>> Not sure under what umbrella we could do that, GSoC, JEP, ... though.
>>
>> Best regards.
>>
>> On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding 
>> wrote:
>>
>>> Jesse - cheers for pointing out the previous AWS packaging attempt, I
>>> will take a look.
>>>
>>> Re version pinning, if this can’t be done in the POM, are there any
>>> Jenkins tools which can do this, apart from the cloudbees assured update
>>> feed? (I’m thinking of how we could support users on Jenkins community
>>> edition.)
>>>
>>> Re what gets included - we could insist that any plugins included in a
>>> cloud vendor metapackage meet certain criteria, so that they can play
>>> together better:
>>> - They must be able to no-op if the user doesn’t need them (ie their
>>> default is to quietly sit on the Jenkins server and not do anything, until
>>> the user configures them).
>>> - They must all use the same cloud provider SDK artifact (probably the
>>> Jenkins re-packaged HPI version of the SDK).
>>> - If appropriate, they must all take their baseline configuration from
>>> the same cloud provider ‘global config’ plugin.
>>>
>>> Re pre-defined packages - I would certainly like to see the cloud
>>> vendors get more involved with supporting their respective Jenkins plugins.
>>>
>>> Chris
>>>
>>> --
>>> 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 jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.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/3b8b4036-9774-40eb-ac99-42ce54a2b6a0%40googlegroups.com
>

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Rick

Hi Oleg,

I wish I could be a mentor of it. But the meeting time is too later for me. I’m
not sure I can be there.

Due to the network blocked issues, I cannot access the google.com about one
month. I try to fix this.

Best,
Rick
On 02/25/2020 17:48，Oleg Nenashev wrote：
Hi all,

I wonder whether we could have a dedicated session for this project idea at one
of the Platform SIG meetings (noon UTC on Thursdays, next one will be on 27th).

Best regards,
Oleg

P.S: We are looking for potential GSoC project mentors! If you are interested
in mentoring this project idea, let the GSoC team know!

On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León Jiménez
wrote:
Hi.

Not sure under what umbrella we could do that, GSoC, JEP, ... though.

Best regards.

On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding wrote:

Jesse - cheers for pointing out the previous AWS packaging attempt, I will take
a look.

Re pre-defined packages - I would certainly like to see the cloud vendors get
more involved with supporting their respective Jenkins plugins.

Chris

--
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/3b8b4036-9774-40eb-ac99-42ce54a2b6a0%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/1281a09.2371.1707bc6d370.Coremail.zxjlwt%40126.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Oleg Nenashev

Hi all,

Some notes about this topic from the contributor summit in Brussels are 
available here: 
https://docs.google.com/document/d/1-OGpDPWkOdKw-e8C0v9hUGgQshCLmToodo0biwlejdk/edit#heading=h.wzuq89kuh5wy
Maybe Chris or Tim could add more notes there as the most active 
participants, but I also believe that this project idea and the topics 
there are very well aligned. Thanks a lot to everyone who contributed to 
this discussion

I wonder whether we could have a dedicated session for this project idea at 
one of the Platform SIG meetings 
 (noon UTC on Thursdays, next 
one will be on 27th).


Best regards,
Oleg

P.S: We are looking for potential GSoC project mentors! If you are 
interested in mentoring this project idea, let the GSoC team know!



On Tuesday, February 25, 2020 at 9:40:34 AM UTC+1, Manuel Ramón León 
Jiménez wrote:
>
> Hi.
>
> I've been working on some ideas pretty similar to all you are suggesting 
> here. The ultimate goal is, sort of:
> * Allow to have a Jenkins ready with all stuff in a single click or 
> command. Or compared to IKEA: avoid having to mount the IKEA furniture 
> manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka 
> plugins) and people usually don't know what to use to get their furniture 
> mounted :-) 
> * Allow people to share "their Jenkins", meaning Jenkins version + 
> plugins + sample-running jobs + configurations (but credentials) to allow 
> community to reuse them. Some projects have contributed to allow that 
> without too much effort, like JCasC, custom-war-packager, ...
> * Allow people to kind of vote for packages to be able to find out the 
> most mature or relevant among all existing.
> * Have a centralized and easy to maintain repository of such "Jenkins 
> configurations". It could be as easy as a GH repo with a certain template 
> (readme + configuration file + assets), although some features like voting 
> may be missed.
>
> Beyond the specific proposal I made I find there are a lot of people 
> thinking on the same problem and slightly different solutions. So it would 
> be great to align efforts on the same direction to extract the most from us 
> to achieve something deliverable in a short time.
>
> Not sure under what umbrella we could do that, GSoC, JEP, ... though.
>
> Best regards.
>
> On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding  > wrote:
>
>> Jesse - cheers for pointing out the previous AWS packaging attempt, I 
>> will take a look.
>>
>> Re version pinning, if this can’t be done in the POM, are there any 
>> Jenkins tools which can do this, apart from the cloudbees assured update 
>> feed? (I’m thinking of how we could support users on Jenkins community 
>> edition.)
>>
>> Re what gets included - we could insist that any plugins included in a 
>> cloud vendor metapackage meet certain criteria, so that they can play 
>> together better:
>> - They must be able to no-op if the user doesn’t need them (ie their 
>> default is to quietly sit on the Jenkins server and not do anything, until 
>> the user configures them).
>> - They must all use the same cloud provider SDK artifact (probably the 
>> Jenkins re-packaged HPI version of the SDK).
>> - If appropriate, they must all take their baseline configuration from 
>> the same cloud provider ‘global config’ plugin.
>>
>> Re pre-defined packages - I would certainly like to see the cloud vendors 
>> get more involved with supporting their respective Jenkins plugins.
>>
>> Chris
>>
>> -- 
>> 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 jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.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/3b8b4036-9774-40eb-ac99-42ce54a2b6a0%40googlegroups.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-02-25 Thread Manuel Ramón León Jiménez

Hi.

I've been working on some ideas pretty similar to all you are suggesting
here. The ultimate goal is, sort of:
* Allow to have a Jenkins ready with all stuff in a single click or
command. Or compared to IKEA: avoid having to mount the IKEA furniture
manually because unlike IKEA, we have dozens of *Shrönghon screw* (aka
plugins) and people usually don't know what to use to get their furniture
mounted :-)
* Allow people to share "their Jenkins", meaning Jenkins version +
plugins + sample-running jobs + configurations (but credentials) to allow
community to reuse them. Some projects have contributed to allow that
without too much effort, like JCasC, custom-war-packager, ...
* Allow people to kind of vote for packages to be able to find out the most
mature or relevant among all existing.
* Have a centralized and easy to maintain repository of such "Jenkins
configurations". It could be as easy as a GH repo with a certain template
(readme + configuration file + assets), although some features like voting
may be missed.

Beyond the specific proposal I made I find there are a lot of people
thinking on the same problem and slightly different solutions. So it would
be great to align efforts on the same direction to extract the most from us
to achieve something deliverable in a short time.

Not sure under what umbrella we could do that, GSoC, JEP, ... though.

Best regards.

On Mon, Feb 24, 2020 at 11:55 PM Chris Kilding <
chris+jenk...@chriskilding.com> wrote:

> Jesse - cheers for pointing out the previous AWS packaging attempt, I will
> take a look.
>
> Re version pinning, if this can’t be done in the POM, are there any
> Jenkins tools which can do this, apart from the cloudbees assured update
> feed? (I’m thinking of how we could support users on Jenkins community
> edition.)
>
> Re what gets included - we could insist that any plugins included in a
> cloud vendor metapackage meet certain criteria, so that they can play
> together better:
> - They must be able to no-op if the user doesn’t need them (ie their
> default is to quietly sit on the Jenkins server and not do anything, until
> the user configures them).
> - They must all use the same cloud provider SDK artifact (probably the
> Jenkins re-packaged HPI version of the SDK).
> - If appropriate, they must all take their baseline configuration from the
> same cloud provider ‘global config’ plugin.
>
> Re pre-defined packages - I would certainly like to see the cloud vendors
> get more involved with supporting their respective Jenkins plugins.
>
> Chris
>
> --
> 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/623C5041-5D06-47C9-BD2F-CA7336B7BC53%40chriskilding.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/CAHHyvkM2xJjf90UsYyeeQJGxjH%2Buc59XoJRFXchf%3DLHs-h5Rng%40mail.gmail.com.

Re: About - Simple Pull Request Plugin

2020-02-25 Thread Aytunc Beken

Hi Oleg,

First I want to focus on this new Pipeline As Yaml Plugin. After that, I 
can work in this plugin (SPPR) also.

So thanks a lot for the support, I will start working on this plugin 
immediately.


On Monday, February 24, 2020 at 2:03:32 PM UTC+1, Oleg Nenashev wrote:
>
> Hi Aytunc,
>
> - Of course, I do not want to throw all the effort in the SPPR, I may use 
>> some of the codes from there, if it is okay ?
>>
> As long as you follow the MIT License requirements, sure.
> You may also want to consider taking over this plugin or contributing to 
> its codebase, but it is up to you.
> Obviously, it would be great to have this new plugin as oprn-source.
>
> - @Oleg, I saw that this plugin is also selected for GSC 2020, I want to 
>> be sure that, writing this plugin will not affect GSC 2020 or any other 
>> Jenkins/Community Projects
>>
>
> GSoC 2020 lists potential project ideas, it is not a problem if some ideas 
> overlap with pending work. Students would need to consider the ongoing 
> developments in their project proposals, and ideally to sync-up with 
> stakeholders in the dev list.
> It would be great to put a notice with a link to this thread so that 
> potential applicants know there is ongoing parallel effort.
>
> BR, Oleg
>
>
>
> On Sat, Feb 22, 2020 at 2:25 PM Aytunc Beken  > wrote:
>
>> Hi Vu Tuan,
>>
>> Thank you for the detailed information about the plugin. So in this 
>> situation, my suggestions are below.
>>
>> - As the SPPR plugin is not developed any more and name of the plugin do 
>> match with its purpose, starting a new plugin for PAY ( Pipeline As Yaml) 
>> will be more accurate. 
>> - Of course, I do not want to throw all the effort in the SPPR, I may use 
>> some of the codes from there, if it is okay ? 
>> - @Oleg, I saw that this plugin is also selected for GSC 2020, I want to 
>> be sure that, writing this plugin will not affect GSC 2020 or any other 
>> Jenkins/Community Projects.
>>
>> Thanks.
>>
>>
>> On Saturday, February 22, 2020 at 2:13:34 PM UTC+1, Vu Tuan Pham wrote:
>>>
>>> Hi Aytunc,
>>>
>>> Thank you for reaching out to me. To give you some context, I took over 
>>> this project from a GSoC project (Google Summer of Code) from a student. He 
>>> was unable to finish the project on time, so I decided to take it over 
>>> after GSoC to see if I can continue working on it to bring it to official 
>>> release (1.0). Unfortunately, due to time permit and some of my personal 
>>> reasons, I haven't had time to maintain it over the past 2 years.
>>>
>>> However, I can still help you my question at my best:
>>> - At first, the intend was to integrate with multiple version control 
>>> systems as it mentioned in the description of the repo 
>>> https://github.com/jenkinsci/simple-pull-request-job-plugin. But 
>>> overtime, I think the target shifted toward Pipeline as YAML, which the 
>>> name of the plugin is not reflecting what it is doing.
>>> - As I mentioned, iiuc, this project is no longer under development by 
>>> anybody, so if you have any idea about a new project, you can always 
>>> proceed ahead. If you think SPPR project is useful in some ways, you can 
>>> also consider merging 2 projects, there is no restriction for you to do 
>>> that.
>>>
>>> To understand more about this project, you can watch these presentation 
>>> videos during GSoC 2018 (can skip to SPPR plugin presentation):
>>> https://www.youtube.com/watch?v=qWHM8S0fzUw=youtu.be
>>> https://www.youtube.com/watch?v=tuTODhJOTBU=youtu.be
>>> https://www.youtube.com/watch?v=GGEtN4nbtng=youtu.be
>>>
>>> cc ...@Martin d'Anjou, who is the mentor of this project during GSoC 
>>> 2018. I think Martin can give you some insights on the project.
>>> Let us know if you have any further questions.
>>>
>>> Thanks,
>>> Vu Tuan
>>>
>>> On Wednesday, February 19, 2020 at 4:54:07 AM UTC+8, Aytunc Beken wrote:

 Hi Oleg, 

 Nice to meet you Vu Tuan. 

 I have some doubts, may be you can help me understand things.

 - Why the name of the plugin is different ? Also It says it is about 
 pull requests from various version controls. If this plugin will continue 
 focusing on both, It will be good to separate them.
 - I was planing to use ModelASTPipelineDef 
 (org.jenkinsci.plugins.pipeline.modeldefinition.ast) for converting Yaml 
 to 
 Jenkins and vice versa. As this is internal model of Declarative pipeline, 
 It will be easy to maintain.

 I will be glad if I can get your ideas/comment about these.

 Thanks. Regards

>>> -- 
>> 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/6ieyOlLQX0I/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>>

Re: LTS baseline selection

Re: LTS baseline selection

Re: LTS baseline selection

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: LTS baseline selection

Re: LTS baseline selection

Re: LTS baseline selection

Re: JAMS in meetup account disappearing

Re: JAMS in meetup account disappearing

Re: LTS baseline selection

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: LTS baseline selection

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

Re: About - Simple Pull Request Plugin

19 matches

Site Navigation

Mail list logo

Footer information