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

[Liam Newman]

Here's the PR submitting JEP for Digester Removal:
https://github.com/jenkinsci/jep/pull/361

On Wed, May 5, 2021 at 10:37 AM Oleg Nenashev 
wrote:

> Hi all. Please do not consider JEP as a huge overhead. As discussed in
> another thread, we will be working on simplifying the process for
> contributors. The process is not meant to be an obstacle, and I plan to
> keep simplifying it where possible.
> And, to everyone, please be kind. All of us share the goal to improve
> Jenkins and reduce maintenance overheads
>
> On Wednesday, May 5, 2021 at 7:13:42 PM UTC+2 Baptiste Mathus wrote:
>
>>
>> Le mer. 5 mai 2021 à 19:08, Jesse Glick  a écrit :
>>
>>> On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev 
>>> wrote:
>>>
 What about a quick JEP?

>>>
>>> The rule of thumb is that if you are not sure if a JEP might be
>>> needed…file a JEP. It is how we document any decision that might be
>>> controversial or require explanation or context. Certainly any
>>> deliberate compatibility break falls into this category. If your arguments
>>> for why we should do something are coherent, it should not take long to
>>> write up a few paragraphs in AsciiDoc and file it.
>>>
>>
>> Agreed. We'll do one
>>
>>
>> --
> 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/f8066f0c-9dfe-4209-8fe8-e19bcf30b8e7n%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/CAA0qCNyOnh-O1o%2Bo2srtHd38G%3DQbpYA6mDS2Wt6T8M0f4ahJqw%40mail.gmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Liam Newman]

>
> Please no, wiki's suck for quality documentation.
>

+1000


On Thu, May 6, 2021 at 6:57 AM Tim Jacomb  wrote:

> Please no, wiki's suck for quality documentation.
>
> Anyone can put whatever rubbish they want there.
>
> On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure <
> jenkins-in...@googlegroups.com> wrote:
>
>> Hi Everybody,
>>
>> During the last Infrastructure meeting
>> ,
>> Daniel Beck came with an interesting question.
>>
>> Considering the proliferation of Google documents and other random tools
>> to take notes,
>> shouldn't we consider bringing back Confluence?
>>
>> While I am not convinced that a wiki is THE solution, I definitely share
>> his frustration.
>> I feel we did a major step backward in terms of knowledge management
>> across the Jenkins project.
>>
>> Nowadays, the default behavior is to create a Google document to take
>> notes during meetings or event organizations.
>> This approach is very easy for synchronous collaboration but it also has
>> bad side effects. It's difficult to find old documents unless you
>> bookmarked them. And, documents lifecycle are affected by the "new" google
>> storage policy or corporate google accounts.
>>
>> Historically, we used the wiki to take notes and write documentation.
>> https://wiki.jenkins.io/display/JENKINS
>> That central place was really convenient to share and find information
>> across community initiatives.
>>
>> That being said, I didn't forget the reasons to move away from
>> Confluence, and here are some of them:
>>
>> 1. Spammers, because of the nature of the Jenkins project we tend to
>> attract a lot of spammers. Then *someone* has to do some clean-up.
>> 2. Maintaining confluence is a major distraction that nobody wants to do.
>> 3. Confluence in the current state is very slow mainly due to point 2 and
>> due to unfinished infrastructure work.
>>
>> The two last elements could be solved by asking the Linux Foundation to
>> maintain Confluence. The same way they do for Jira
>> 
>> Also, it's worth keeping in mind that Atlassian is deprecating their
>> on-prem solution in 2024.
>>
>> Several weeks ago, I started an experiment on the infrastructure project
>> to use hackmd.io to allow synchronous collaboration on meeting notes.
>> During a meeting or a maintenance window, everybody can participate then
>> at the end of the meeting someone pushes the notes to a git repository like
>> https://github.com/jenkins-infra/documentation/#documentation
>> To me it combines two approaches, it's as easy as a Google document to
>> collect notes and then we can easily store them on a git repository
>> directly in Markdown.
>> Unfortunately, I am not convinced by the asynchronous collaboration
>> workflow.
>>
>> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the
>> poor video)
>>
>> As I said it's an experiment, the purpose is to simplify synchronous
>> collaboration and then persist the content on a git repository that can
>> easily be browsed.
>>
>> I would be curious to know your feeling about all of this and if you have
>> other suggestions.
>>
>> Cheers
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Infrastructure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkins-infra+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.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-3BidiAX87%2BDenOYkqw2ArtQCc6HRXpNZ-r4To5gh2vNC7aQ%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/CAA0qCNzn-0nbF%2BcR%2BaVv5AXLovk8xchMKT2-GBt6s4Z3WqaW2g%40mail.gmail.com.

Re: JEPs & BDFL ~ KK

[Liam Newman]

Oleg,

I just thought of one more possible change.  Instead of having proposed
JEPs sit as PRs until they meet the bar for "Draft", we should add a
"sandbox" folder with named subfolders. So instead of having one pre-draft
folder "" we can have many.  This would allow people to more easily
collaborate on getting JEPs to Draft state.  Alternatively, we could have a
jep-sandbox fork that holds the JEP sandbox (keeping the jep repo cleaner).
That repo would have a wiki-style editing policy with a very low bar for
getting contributor status, letting people make changes without PRs.

-L.



On Wed, May 5, 2021 at 11:30 AM Liam Newman  wrote:

> I can't attend the governance meeting but I'm +1 on the changes we've
> discussed.
>
> On Tue, May 4, 2021 at 1:09 PM Oleg Nenashev 
> wrote:
>
>> Thanks! I will create a pull request for the JEP tomorrow. No laptop at
>> the moment
>>
>> On Tue, May 4, 2021, 21:44 Liam Newman  wrote:
>>
>>> All this sounds good to me.  Thanks for working on this.
>>> -L.
>>>
>>>
>>> On Tue, May 4, 2021 at 10:00 AM Oleg Nenashev 
>>> wrote:
>>>
>>>> Hi Liam,
>>>>
>>>> "Advisor" looks good to me. Although we would not be using the same
>>>> terminology as in Java JEPs, I agree using this name would help. So I would
>>>> prefer to choose the "Champion/Advisor" pair then.
>>>> For sign-off, I think that the standard Jenkins open governance process
>>>> allows that:
>>>>
>>>>- The Jenkins Developer mailing list provides a trace of those who
>>>>sign-off the proposal asynchronously
>>>>- The Governance meeting agenda and recording keep trace of votes
>>>>at the Governance meeting. We can communicate them back to the developer
>>>>mailing list explicitly
>>>>- If a decision is delegated to an entity like SIG, it is again
>>>>traceable on its level
>>>>- If a decision is delegated to a single contributor, this
>>>>contributor becomes that "reviewer"
>>>>
>>>> The main problem with this process is versioning. What if the proposal
>>>> gets changed during the approval process? How do we track that and whether
>>>> the borderline between small change and one requiring re-approvals? I do
>>>> not have exact answer to this. What we could do is the "ready to publish"
>>>> state:
>>>>
>>>>- When a proposal is approved at the "open governance process", a
>>>>pull request is submitted to transfer the proposal to the
>>>>Active/Accepted/Final state
>>>>- There is a timeout similar to "ready-for-merge" in the Jenkins
>>>>core PRs. If there is no negative feedback until the timeout, the 
>>>> proposal
>>>>gets merged. The timeout time is TBD, but I would not like it to be more
>>>>than 1 week
>>>>- JEP Champions or an Advisor are expected to explicitly
>>>>communicate the merge countdown in the discussion thread
>>>>
>>>> What do you think?
>>>>
>>>> Best regards,
>>>> Oleg
>>>>
>>>>
>>>>
>>>>
>>>> On Tuesday, May 4, 2021 at 5:49:03 PM UTC+2 bitwi...@gmail.com wrote:
>>>>
>>>>> Oleg,
>>>>>
>>>>> I agree that the names of the roles matter and "Champion/Owner"
>>>>> definitely is more descriptive.
>>>>> My main concern is confusion around the repurposing of the term
>>>>> "Sponsor".  I would agree to this if we can avoid name collision.  What
>>>>> about "Advisor" or "Mentor"?
>>>>>
>>>>> Everyone should review JEPs they are involved in, but there still
>>>>> needs to be an explicit list of "Reviewers" that sign off on a JEP.
>>>>>
>>>>> I look forward to feedback from others on this thread.
>>>>>
>>>>> -L.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 3, 2021 at 2:16 PM Oleg Nenashev 
>>>>> wrote:
>>>>>
>>>>>> In the case changing "Sponsor" -> "Champion/Owner" and adding "(New
>>>>>>> role) Sponsor", I'm not convinced there's a huge win there.  We alread

Re: JEPs & BDFL ~ KK

[Liam Newman]

I can't attend the governance meeting but I'm +1 on the changes we've
discussed.

On Tue, May 4, 2021 at 1:09 PM Oleg Nenashev  wrote:

> Thanks! I will create a pull request for the JEP tomorrow. No laptop at
> the moment
>
> On Tue, May 4, 2021, 21:44 Liam Newman  wrote:
>
>> All this sounds good to me.  Thanks for working on this.
>> -L.
>>
>>
>> On Tue, May 4, 2021 at 10:00 AM Oleg Nenashev 
>> wrote:
>>
>>> Hi Liam,
>>>
>>> "Advisor" looks good to me. Although we would not be using the same
>>> terminology as in Java JEPs, I agree using this name would help. So I would
>>> prefer to choose the "Champion/Advisor" pair then.
>>> For sign-off, I think that the standard Jenkins open governance process
>>> allows that:
>>>
>>>- The Jenkins Developer mailing list provides a trace of those who
>>>sign-off the proposal asynchronously
>>>- The Governance meeting agenda and recording keep trace of votes at
>>>the Governance meeting. We can communicate them back to the developer
>>>mailing list explicitly
>>>- If a decision is delegated to an entity like SIG, it is again
>>>traceable on its level
>>>- If a decision is delegated to a single contributor, this
>>>contributor becomes that "reviewer"
>>>
>>> The main problem with this process is versioning. What if the proposal
>>> gets changed during the approval process? How do we track that and whether
>>> the borderline between small change and one requiring re-approvals? I do
>>> not have exact answer to this. What we could do is the "ready to publish"
>>> state:
>>>
>>>- When a proposal is approved at the "open governance process", a
>>>pull request is submitted to transfer the proposal to the
>>>Active/Accepted/Final state
>>>- There is a timeout similar to "ready-for-merge" in the Jenkins
>>>core PRs. If there is no negative feedback until the timeout, the 
>>> proposal
>>>gets merged. The timeout time is TBD, but I would not like it to be more
>>>than 1 week
>>>- JEP Champions or an Advisor are expected to explicitly communicate
>>>the merge countdown in the discussion thread
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>>
>>>
>>> On Tuesday, May 4, 2021 at 5:49:03 PM UTC+2 bitwi...@gmail.com wrote:
>>>
>>>> Oleg,
>>>>
>>>> I agree that the names of the roles matter and "Champion/Owner"
>>>> definitely is more descriptive.
>>>> My main concern is confusion around the repurposing of the term
>>>> "Sponsor".  I would agree to this if we can avoid name collision.  What
>>>> about "Advisor" or "Mentor"?
>>>>
>>>> Everyone should review JEPs they are involved in, but there still needs
>>>> to be an explicit list of "Reviewers" that sign off on a JEP.
>>>>
>>>> I look forward to feedback from others on this thread.
>>>>
>>>> -L.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 3, 2021 at 2:16 PM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> In the case changing "Sponsor" -> "Champion/Owner" and adding "(New
>>>>>> role) Sponsor", I'm not convinced there's a huge win there.  We already
>>>>>> define a "Reviewer" role as an alias for "BDFL and BDFL Delegate".   If 
>>>>>> we
>>>>>> replace the "BDFL Delegate" field with "Reivewer" wouldn't that be
>>>>>> sufficient?  It would be significantly less confusing than changing the
>>>>>> meaning of an existing term.
>>>>>
>>>>> Might be. I just wanted to align the "sponsor" term with how it is
>>>>> used in other projects. In our case "sponsors/JEP-1" are de-facto authors.
>>>>> Maybe a one-time term change would be less confusing for 3rd parties in 
>>>>> the
>>>>> future.
>>>>>
>>>>> For "Reviewer", this is not exactly what I propose. IMO every
>>>>> interested party is expected to review a JEP. The job of the suggested
>>>>> "sponsor" ro

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

[Liam Newman]

Daniel,

>From that link:

> This is not to say we don’t ever remove anything, but we do it very
> carefully.
>

We are being careful.  I think creating a JEP, even a mostly retrospective
one, is worth doing.  If nothing else we should do so because of concerns
like those voiced by Daniel. I will take that task on myself if needed.

  -L.


On Wed, May 5, 2021 at 5:14 AM Daniel Beck  wrote:

>
>
> > On 5. May 2021, at 09:41, Manuel Ramón León Jiménez <
> manuelramonleonjime...@gmail.com> wrote:
> >
> > I'm against a JEP for Digester removal. It doesn't need it IMO. I'm in
> for anything to avoid us dealing with the same problems in the future. We
> need to modernize Jenkins in many aspects and those old / unmaintained
> plugins are an obstacle and a waste of effort.
>
> Time to delete
> https://www.jenkins.io/project/governance/#compatibility-matters then,
> because looking at this thread, compatibility clearly doesn't matter
> 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/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net
> .
>

-- 
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/CAA0qCNwD%3DMMh5i%2BjeEte6CxRqQ%3DcCVEZqmNMxtPcgC8JUJ_0vA%40mail.gmail.com.

Re: JEPs & BDFL ~ KK

[Liam Newman]

All this sounds good to me.  Thanks for working on this.
-L.


On Tue, May 4, 2021 at 10:00 AM Oleg Nenashev 
wrote:

> Hi Liam,
>
> "Advisor" looks good to me. Although we would not be using the same
> terminology as in Java JEPs, I agree using this name would help. So I would
> prefer to choose the "Champion/Advisor" pair then.
> For sign-off, I think that the standard Jenkins open governance process
> allows that:
>
>- The Jenkins Developer mailing list provides a trace of those who
>sign-off the proposal asynchronously
>- The Governance meeting agenda and recording keep trace of votes at
>the Governance meeting. We can communicate them back to the developer
>mailing list explicitly
>- If a decision is delegated to an entity like SIG, it is again
>traceable on its level
>- If a decision is delegated to a single contributor, this contributor
>becomes that "reviewer"
>
> The main problem with this process is versioning. What if the proposal
> gets changed during the approval process? How do we track that and whether
> the borderline between small change and one requiring re-approvals? I do
> not have exact answer to this. What we could do is the "ready to publish"
> state:
>
>- When a proposal is approved at the "open governance process", a pull
>request is submitted to transfer the proposal to the Active/Accepted/Final
>state
>- There is a timeout similar to "ready-for-merge" in the Jenkins core
>PRs. If there is no negative feedback until the timeout, the proposal gets
>merged. The timeout time is TBD, but I would not like it to be more than 1
>week
>- JEP Champions or an Advisor are expected to explicitly communicate
>the merge countdown in the discussion thread
>
> What do you think?
>
> Best regards,
> Oleg
>
>
>
>
> On Tuesday, May 4, 2021 at 5:49:03 PM UTC+2 bitwi...@gmail.com wrote:
>
>> Oleg,
>>
>> I agree that the names of the roles matter and "Champion/Owner"
>> definitely is more descriptive.
>> My main concern is confusion around the repurposing of the term
>> "Sponsor".  I would agree to this if we can avoid name collision.  What
>> about "Advisor" or "Mentor"?
>>
>> Everyone should review JEPs they are involved in, but there still needs
>> to be an explicit list of "Reviewers" that sign off on a JEP.
>>
>> I look forward to feedback from others on this thread.
>>
>> -L.
>>
>>
>>
>>
>>
>> On Mon, May 3, 2021 at 2:16 PM Oleg Nenashev  wrote:
>>
>>> In the case changing "Sponsor" -> "Champion/Owner" and adding "(New
>>>> role) Sponsor", I'm not convinced there's a huge win there.  We already
>>>> define a "Reviewer" role as an alias for "BDFL and BDFL Delegate".   If we
>>>> replace the "BDFL Delegate" field with "Reivewer" wouldn't that be
>>>> sufficient?  It would be significantly less confusing than changing the
>>>> meaning of an existing term.
>>>
>>> Might be. I just wanted to align the "sponsor" term with how it is used
>>> in other projects. In our case "sponsors/JEP-1" are de-facto authors. Maybe
>>> a one-time term change would be less confusing for 3rd parties in the
>>> future.
>>>
>>> For "Reviewer", this is not exactly what I propose. IMO every interested
>>> party is expected to review a JEP. The job of the suggested "sponsor" role
>>> is to help the authors with the process and with getting the required
>>> community feedback, not necessarily to review the entire JEP and technical
>>> merits on their own.
>>>
>>> Oleg, perhaps you could submit a PR (or more than one) with proposed
>>>> changes?
>>>>
>>> It would be great to reach the consensus first. Then yes, I will submit
>>> the JEP update
>>>
>>>
>>> On Mon, May 3, 2021 at 10:52 PM Liam Newman  wrote:
>>>
>>>> As one of the "Sponsors" of JEP-1, I should probably weigh in.
>>>>
>>>> I support streamlining the JEP process any way the community sees fit
>>>> to do.  Removing the BDFL and BDFL Delegate, replacing them with the
>>>> Governance Board certainly makes sense at this point.  Howver, I don't like
>>>> changing the meaning of existing terms unless it makes the process
>>>> significantly clearer going forward.  In the case 

Re: JEPs & BDFL ~ KK

[Liam Newman]

Oleg,

I agree that the names of the roles matter and "Champion/Owner" definitely
is more descriptive.
My main concern is confusion around the repurposing of the term "Sponsor".
I would agree to this if we can avoid name collision.  What about "Advisor"
or "Mentor"?

Everyone should review JEPs they are involved in, but there still needs to
be an explicit list of "Reviewers" that sign off on a JEP.

I look forward to feedback from others on this thread.

-L.





On Mon, May 3, 2021 at 2:16 PM Oleg Nenashev  wrote:

> In the case changing "Sponsor" -> "Champion/Owner" and adding "(New role)
>> Sponsor", I'm not convinced there's a huge win there.  We already define a
>> "Reviewer" role as an alias for "BDFL and BDFL Delegate".   If we replace
>> the "BDFL Delegate" field with "Reivewer" wouldn't that be sufficient?  It
>> would be significantly less confusing than changing the meaning of an
>> existing term.
>
> Might be. I just wanted to align the "sponsor" term with how it is used in
> other projects. In our case "sponsors/JEP-1" are de-facto authors. Maybe a
> one-time term change would be less confusing for 3rd parties in the future.
>
> For "Reviewer", this is not exactly what I propose. IMO every interested
> party is expected to review a JEP. The job of the suggested "sponsor" role
> is to help the authors with the process and with getting the required
> community feedback, not necessarily to review the entire JEP and technical
> merits on their own.
>
> Oleg, perhaps you could submit a PR (or more than one) with proposed
>> changes?
>>
> It would be great to reach the consensus first. Then yes, I will submit
> the JEP update
>
>
> On Mon, May 3, 2021 at 10:52 PM Liam Newman  wrote:
>
>> As one of the "Sponsors" of JEP-1, I should probably weigh in.
>>
>> I support streamlining the JEP process any way the community sees fit to
>> do.  Removing the BDFL and BDFL Delegate, replacing them with the
>> Governance Board certainly makes sense at this point.  Howver, I don't like
>> changing the meaning of existing terms unless it makes the process
>> significantly clearer going forward.  In the case changing "Sponsor" ->
>> "Champion/Owner" and adding "(New role) Sponsor", I'm not convinced there's
>> a huge win there.  We already define a "Reviewer" role as an alias for
>> "BDFL and BDFL Delegate".   If we replace the "BDFL Delegate" field with
>> "Reivewer" wouldn't that be sufficient?  It would be significantly less
>> confusing than changing the meaning of an existing term.
>>
>> As for the other changes, I suggest folks reread the Motivation for JEP-1
>> <https://github.com/jenkinsci/jep/tree/master/jep/1#motivation> - one of
>> the main goals of the process is to document how decisions were reached.
>> Switching to "focus on the feature delivery process" misses the point
>> - creating and updating the JEP document should be part of the feature
>> delivery process. Encouraging consensus-driven design, tracking current
>> design state and discussion, and documenting the reasons various design
>> decisions were made is vital not only to lowering the barrier to entry for
>> new contributors, but also to improving the velocity of updates and
>> improvements.
>>
>> I understand creating and maintaining these kinds of documents is hard. I
>> have at least two features I've implemented that should have JEPs and do
>> not yet. Shame on me. However, I still think it is important to not
>> "streamline" away key parts of why we have JEPs in the first place. It is
>> better to have a slightly heavier process that isn't always done perfectly
>> than to have a lighter process that doesn't achieve what it was intended to.
>>
>> Oleg, perhaps you could submit a PR (or more than one) with proposed
>> changes?
>>
>> -L.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 3, 2021 at 2:15 AM Oleg Nenashev 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am not sure this is the last conversation about the JEPs process, but
>>> as a JEP Editor I would like to recover it. Currently the JEP process does
>>> NOT workm neither for the original inspiration s nor for the documentation
>>> purposes. We have multiple JEPs created recently, but they get stuck
>>> overall. Thanks to Jesse, Daniel Beck, Wadeck, Sumit Sarin and Tim Jacomb

Re: JEPs & BDFL ~ KK

[Liam Newman]

As one of the "Sponsors" of JEP-1, I should probably weigh in.

I support streamlining the JEP process any way the community sees fit to
do.  Removing the BDFL and BDFL Delegate, replacing them with the
Governance Board certainly makes sense at this point.  Howver, I don't like
changing the meaning of existing terms unless it makes the process
significantly clearer going forward.  In the case changing "Sponsor" ->
"Champion/Owner" and adding "(New role) Sponsor", I'm not convinced there's
a huge win there.  We already define a "Reviewer" role as an alias for
"BDFL and BDFL Delegate".   If we replace the "BDFL Delegate" field with
"Reivewer" wouldn't that be sufficient?  It would be significantly less
confusing than changing the meaning of an existing term.

As for the other changes, I suggest folks reread the Motivation for JEP-1
 - one of
the main goals of the process is to document how decisions were reached.
Switching to "focus on the feature delivery process" misses the point
- creating and updating the JEP document should be part of the feature
delivery process. Encouraging consensus-driven design, tracking current
design state and discussion, and documenting the reasons various design
decisions were made is vital not only to lowering the barrier to entry for
new contributors, but also to improving the velocity of updates and
improvements.

I understand creating and maintaining these kinds of documents is hard. I
have at least two features I've implemented that should have JEPs and do
not yet. Shame on me. However, I still think it is important to not
"streamline" away key parts of why we have JEPs in the first place. It is
better to have a slightly heavier process that isn't always done perfectly
than to have a lighter process that doesn't achieve what it was intended to.

Oleg, perhaps you could submit a PR (or more than one) with proposed
changes?

-L.








On Mon, May 3, 2021 at 2:15 AM Oleg Nenashev  wrote:

> Hi all,
>
> I am not sure this is the last conversation about the JEPs process, but as
> a JEP Editor I would like to recover it. Currently the JEP process does NOT
> workm neither for the original inspiration s nor for the documentation
> purposes. We have multiple JEPs created recently, but they get stuck
> overall. Thanks to Jesse, Daniel Beck, Wadeck, Sumit Sarin and Tim Jacomb
> for the recent JEP updates. It is important to keep doing so, but it is
> important to have the process more lightweight and active.
>
> To address the JEP stagnation issue, I suggest the following changes:
>
>- We remove the "BDFL" and ""BDFL Delegate" concepts from the JEP
>process. Instead of that, the Jenkins governance process applies. The
>"acceptance" decision is made by a consensus in the mailing list or voting
>at the governance meeting. These entities can also delegate the final
>decision to another group (e.g. SIG) or individual contributor
>   - Note: JEP-1 is the only place where the Jenkins BDFL
>    role
>   is used. If Kohsuke agrees, we could abolish this role similarly to what
>   the Python community did. Kohsuke will always remain the Founder of
>   Jenkins, and this is the role which will stay forever. Kohsuke will also
>   remain the permanent member of the Jenkins Governance Board until he
>   decides to step down
>   - At one of the next Governance meetings, we do a bulk review of
>the JEPs and approve changing status for those which were de-facto
>delivered (e.g., Remoting over Websockets by Jesse).
>- We extend the team of JEP Editors and add experienced JEP
>contributors there, e.g. Jesse Glick, Daniel Beck, Tim Jacomb
>
> To simplify the process, I also suggest the following:
>
>- We introduce the "JEP Champion" (or "JEP Owner") term. It is
>basically how we handle "Sponsors" in JEP-1 now. This role lists all
>contributors driving the JEP discussion and delivery, including the
>original author. Champions may be added as the JEP evolves.
>   - Note: I do not suggest "JEP Author" or "JEP Contributor", because
>   we target wide feedback and contributions from many participants. We 
> have a
>   Git history for that.
>   - We introduce a new *optional *"JEP Sponsor" column. This is used
>in the case when a less experienced contributor submits a JEP and becomes a
>JEP champion. A sponsor is a nominated or a self-nominated experienced
>contributor who helps the champion(s) do go through the JEP process and,
>particularly, to ensure there is a public discussion and a consensus built
>around accepting the JEP, and thaen the Governance decision making process.
>
> The changes will need explicit approval from Kohsuke, but I believe we
> have his support for the process update part. Abolishing the BDFL term is a
> separate topic which does not block 

Re: Optional automated source code formatting - prep for JEP

[Liam Newman]

Thanks you two, for clearly describing the issue that I'm attempting to 
address.  
I've updated 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392 with the 
following changes: 

   - Source will not be changed during the build unless the user runs a 
   specific maven goal
   - "spotless:check" runs near the end of the lifecycle during the verify 
  phase during local build.  Formatting issues will fail the build, source 
  remains unchanged. 
  - "spotless:check" runs near the start  of the lifecycle during the 
  process-sources phase during CI. Formatting issues will fail the build, 
  source remains unchanged. 
  - Users may run "mvn spotless:apply" to automatically fix 
  formatting.  This command is easy and short.  When "spotless:check" fails 
  it specifically tells users to run "mvn spotless:apply" to fix formatting.
   - I have adjusted the formatting rules to address some of the points 
   raised during review
   - Line comments do not join if wrapped - if you have comments that you 
  want to not be reformatted, keep them under 120 chars and use line 
comments
  - Javadoc formatting made a bit more compact 
  - 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392/commits/ea6e28ca69ea24a59584fba3c6190b145dc0925e
  - Found a way to force array initializer expansion if that is what is 
  desired 
  - 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392/commits/43a99508ab640db724e8b673c61855cb57670b82
  - Long string arguments getting pushed to the next line?  Maybe the 
  humans involved should split those 
  up. 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580403349
  - I've applied the ".gitattributes" suggested by Joseph.  The build 
  now passes on Windows.
   - I have also not addressed a number of other places where people have 
   said the formatting looks "worse". These cases are generally 
   debatable/personal-preference.  In some of these cases I agree with the 
   assessment but I don't see it as a blocker.  If anyone disagrees with that 
   evaluation, feel free to say so and explain why.  
  - 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580104724
 
  - 
  see 
https://github.com/bitwiseman/github-branch-source-plugin/pull/new/task/formatting-test-cleanup
  - 
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580105388
 
  - same as previous
  - 
  
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580402264
  - 
  
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580510020
  - 
  
https://github.com/jenkinsci/github-branch-source-plugin/pull/392#discussion_r580513803
   
Note: I am using the eclipse formatter rather than to google formatter in 
an attempt to reduce the severity of the diff wall and disruption to folks 
familiar with the current code style. There are still significant 
differences, but they are far less than switching to google formatting.  
However, that is still an option. You can see what it would look like 
here: 
https://github.com/bitwiseman/github-branch-source-plugin/pull/new/task/formatting-google
 





On Wednesday, February 24, 2021 at 4:10:26 PM UTC-8 m...@basilcrow.com 
wrote:

> On Wed, Feb 24, 2021 at 3:32 AM jn...@cloudbees.com  
> wrote:
> >
> > What I feel is also missing here is what issue is this attempting to 
> solve.
> > It is proposing a solution - but what is the exact problem maintainers 
> are
> > seeing; perhaps there are better ways to solve that?
>
> The problem, to me, is twofold:
>
> 1. Lack of convenient formatting tools means one has to consciously think
> about formatting when writing new code or changing existing code. This
> slows down the development process.
> 2. Lack of a consistently enforced formatting style throughout a
> repository leads to PRs that change both logic and formatting style.
> This slows down the review process.
>
> Over the years I have led a number of efforts to reformat legacy codebases
> and enforce the new formatting style consistently at build time, both in
> Java (using Google Java Format) and Python (using Black). My experience is
> that while the "diff wall" described by Mark does initially lead to some
> frustration, the long term benefits of a consistently enforced formatting
> style eventually outweigh the initial costs. In my experience, the key
> takeaways are:
>
> 1. Choose a formatting tool that exposes extremely few (if any)
> configuration options and that formats the majority of code at high
> quality.
> 2. Provide developers with a single command (not executed by default) to
> automatically format their code prior to committing it (ideally also
> with IDE integration).
> 3. Enforce that the entire repository is consistently formatted during the
> build system's "verify" phase 

Re: Forked repositories in GitHub

[Liam Newman]

+1000

On Tue, Aug 18, 2020 at 3:20 PM Ullrich Hafner 
wrote:

> +1 from me as well
>
> Am 18.08.2020 um 16:30 schrieb Matt Sicker :
>
> +1 here, especially due to GitHub tooling and apps.
>
> On Tue, Aug 18, 2020 at 8:13 AM Mark Waite 
> wrote:
>
>> +1 from me.
>>
>> On Tuesday, August 18, 2020 at 6:03:07 AM UTC-6 Arnaud Héritier wrote:
>>
>>> and I received a PR
>>> https://github.com/aheritier/build-flow-plugin/pull/2
>>> 
>>>
>>> +1000 for the proposal
>>>
>>>
>>> On Tue, Aug 18, 2020 at 2:01 PM Arnaud Héritier 
>>> wrote:
>>>
 ok I missed :(
 It doesn't make sense to have my repo as primary. I didn't create it
 and never committed to it.
 There is probably a bug in GitHub with forks which were created a long
 time ago

 On Tue, Aug 18, 2020 at 1:58 PM Daniel Beck 
 wrote:

> The repo exists, there's just an additional "jenkinsci/" in the link.
> I have no idea why the GH API behaves inconsistently there.
>
> On Tue, Aug 18, 2020 at 1:50 PM Arnaud Héritier 
> wrote:
>
>> +1 for the proposed plan
>> Something is strange in your export.
>> For example I am supposed to host
>> https://github.com/aheritier/build-flow-plugin (origin) which should
>> be forked to https://github.com/jenkinsci/jenkinsci/build-flow-plugin (
>> doesn't exist)
>> We probably had such repo in the past and it was deleted after I
>> forked it but maybe you could exclude from the list the repos when they
>> aren't existing anymore in the jenkinsci side (not sure how many repos
>> could be like this)
>>
>> On Tue, Aug 18, 2020 at 1:39 PM Daniel Beck  wrote:
>>
>>> Hi everyone,
>>>
>>> I'd like to propose a cleanup of 'fork' relationships of the
>>> repositories in the jenkinsci GitHub organization.
>>>
>>> Background:
>>> For many years, the plugin hosting process has forked existing
>>> repositories. The expectation was always that the new repo in jenkinsci 
>>> was
>>> the canonical 'main' repository, but that wasn't enforced. For the past
>>> year or two, we've even asked maintainers to delete their repository 
>>> after
>>> forking unless there were useful PRs and issues in there already, so 
>>> that
>>> the jenkinsci repo became the 'main' repo (with occasional mishaps if
>>> someone else had forked before us).
>>>
>>> Some people enjoy the "branding" effect that having the source
>>> repository creates. But this comes with downsides: Sometimes GitHub code
>>> search doesn't work, depending on the popularity of the repository. 
>>> Links
>>> to create pull requests sometimes don't work quite right, and INFRA-2697
>>> notes that the GitHub CLI cannot really handle networks where a fork is 
>>> the
>>> "main" repo, probably for the same reason. Having a different repo than
>>> what we consider canonical as the "root" repository confuses users 
>>> trying
>>> to file pull requests or issues on GitHub. It'll get worse once GitHub 
>>> adds
>>> repo-level discussions[1]. Basically, the more stuff is attached to a
>>> repository that isn't trivially cloned/mirrored to forks, the worse it 
>>> gets.
>>>
>>> In terms of security, GitHub for quite some time did not support
>>> security warnings for forks. LGTM.com / GitHub Security Labs still
>>> does not recognize forked repositories. Earlier this year a security
>>> researcher recently used its CodeQL functionality to identify and submit
>>> fixes to pom.xml files referencing plain HTTP Maven repositories, but
>>> couldn't do that for forked repos. In many cases, the source 
>>> repositories
>>> are much less active than the repo in jenkinsci, or the maintainers have
>>> moved on entirely, making this feature unavailable to (other) current
>>> maintainers, or the Jenkins security team.
>>>
>>> The way we create forks is simply not a well-supported use case.
>>>
>>> My proposal therefore is to "unfork" plugin and similar repositories
>>> in the jenkinsci organization. Only repositories that clearly are forks
>>> (e.g. some libraries not maintained by us) would remain forks.
>>>
>>> After checking with GitHub support, the following options exist:
>>>
>>> 1. It is possible to invert the fork relationship. This requires
>>> approval from both repo owners (i.e. jenkinsci and whoever we forked 
>>> from).
>>> 2. It is possible to cut the fork relationship. This requires
>>> approval from the forked repo owner (i.e. jenkinsci).
>>>
>>> And while it is technically possible to re-attach repos to a network
>>> / merge networks, GH support would rather not do that.
>>>
>>> Therefore I propose we implement the following steps:
>>>
>>> 1. We try to contact, wherever possible, whoever we forked from, and
>>> ask them to contact 

Re: ANN: Jenkins release artifacts uploads blockage on June 09, and a temporary downloads issue

[Liam Newman]

I have two releases that I consider high-priority: github-branch-source and 
github-api .

Users have been able to rollback to the previous release to unblock 
themselves, but people who cannot rollback (new installations) remain 
blocked.  




On Friday, June 12, 2020 at 10:05:33 AM UTC-7, Oleg Nenashev wrote:
>
> Dear all,
>
> June 12 update: 
>
>- We continue to work on the accounts migration and will share the 
>next update on Monday
>- Jenkins releases are still blocked. If there are any emergency 
>releases you need to perform, please reply in this thread.
>
> Best regards,
> Oleg Nenashev
>
> On Friday, June 12, 2020 at 6:00:32 PM UTC+2, Oleg Nenashev wrote:
>>
>> Hi Dave,
>>
>> This is an email from the *Step 2. We’ll reset every user password from 
>> the LDAP database*. This one includes a temporary password, and we 
>> expect users to change it after they login into the system.
>>
>> For those who wonder: Yes, the temporary password is sent in plain text 
>> as mentioned above. This is how our current password reset system is 
>> designed. As other projects, we have a decent amount of technical debt in 
>> our infrastructure which we gradually resolve. I have already added 
>> changing the account password reset flow to the outage retrospective list, 
>> an we will be reviewing what to do there after the outage is fully 
>> resolved. Apart from fixing it, migrating to a 3rd-party identity service 
>> is on the table for me (Linux Foundation or GitHub).  If anyone is 
>> interested to participate and to improve the project, the Jenkins 
>> infrastructure team  is 
>> always looking for more contributors!
>>
>> If anyone has concerns about such method and wants to use alternate 
>> channels for encrypted password transfer, please send us a message through 
>> the Jenkins Infrastructure mailing list from your email registered in 
>> Jenkins. In this email please provide your public GPG key so that we can 
>> reset a password again in a secure way.
>>
>> Best regards,
>> Oleg
>>
>> On Friday, June 12, 2020 at 5:07:27 PM UTC+2, Dave Pedu wrote:
>>>
>>> Hello,
>>>
>>> I have received an email linking to this thread. However, it contains a 
>>> plaintext password for my account, despite this:
>>>
>>> > There will be no temporary password in these emails, but there will 
>>> be information pointing to this thread.
>>>
>>> Is this email legitimate or am I being phished? Screenshot attached.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Thursday, June 11, 2020 at 3:07:01 AM UTC-7, Olblak wrote:

 Dear all,

 We are ready to proceed with restoration of the Jenkins account 
 database. Today we are going to restore user LDAP accounts that were 
 created since the First of February 2020 based on the data from Jenkins 
 Jira and the repository Permission Manager metadata data. We will also 
 reset passwords for all users registered in the database.

 Step 1. All users who lost their account will receive an email saying 
 that their accounts were re-created. There will be no temporary password 
 in 
 these emails, but there will be information pointing to this thread.

 Step 2. We’ll reset every user password from the LDAP database, it is 
 more than 100 000 users. Once done, you’ll receive an email telling you 
 that your password was reset with a reason containing a link to this mail 
 thread.

 Step 3. We will delete accounts of users who requested such deletion 
 between February and June 2020. These users were restored from the backup, 
 so we have to delete them again.The list of users is based on Jira tickets 
 and private messages to the Jenkins Infra officer. If for some reason you 
 notice that your account still exists, feel free to raise a ticket in 
 Jenkins 
 Jira  (project=INFRA, component=account
 ).

 Please do not hesitate to contact us using the #jenkins-infra channel 
 on Freenode IRC or the Jenkins Infrastructure mailing list if you have any 
 questions or suggestions. If you see a security issue related to the 
 accounts, please follow the vulnerability reporting guidelines 
 .

 Best regards,

 Olivier Vernin && Jenkins Infrastructure Team


 On Tuesday, 9 June 2020 17:00:25 UTC+2, Oleg Nenashev wrote:
>
> Dear all,
>
> As you may have noticed, the release artifact uploads are currently 
> blocked in the Jenkins Artifactory instances (
> https://repo.jenkins-ci.org/). We are doing a security investigation 
> due to a partial user database loss on June 02. Today we blocked releases 
> to the Jenkins artifactory, and there also was a temporary outage of the 
> Artifactory downloads which was a collateral damage of the temporary 
> permissions. You 

Re: Prevent building branches/PRs existing before the first branch indexing (Branch API plugin)

[Liam Newman]

Adam, 
I think the feature/behavior you're suggesting is definitely worth 
implementing.  It would let people safely create new projects without 
dealing with build storms.

So to reiterate - the behavior we're looking for is:

   1. Project is created
   2. Branches are indexed, but not built
   3. Polling (or hooks) now enabled
   4. Scheduled indexing now auto-builds new branches if selected. Hooks 
   will trigger builds

You mentioned SkipInitialBuildOnFirstBranchIndexing 

 .  
I think something like that is way to go here.  Only instead of disabling 
the "first indexing of each branch", it would be "Skip Build on First Job 
Indexing".  I know there are several possible ways ways to detect the state 
"this is the first time a project has been indexed", but I'm not 
sufficiently knowledgable to be able to point you to the exact right spot.  
Sorry. But I firmly believe this should be doable without changing the SCM 
or Branch API.  We just need to do some digging to find it.  

Sound good? 

-L. 

On Sunday, April 19, 2020 at 7:44:47 AM UTC-7, Adam Gabryś wrote:
>
> There are two strategies for building PRs:
> 1) test PR before the merge operation - the same as building the source 
> branch
> 2) test PR after the (virtual) merge operation - presents the state after 
> merging
>
> We use a second strategy, because the source branch could work standalone, 
> but break everything with the latest changes.
>
> It means that if we force developers to create a draft PR to just execute 
> a build, they will have to:
> * create a new branch from the branch which is interesting for them
> * create a PR from the new branch to the existing branch
> I don't believe any developer would like to use such flow.
>
> > correct but it will build interesting branches not dangling ones.
>
> I'm confused about these "interesting" branches and filtering by regex. In 
> my company people use Git-Flow 
> . Branches are 
> created to work on new features or bug fixes. I would classify all code 
> changes as interesting to execute on the CI.
>

-- 
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/9c8b5674-4d91-4b31-927c-2981ffac0112%40googlegroups.com.

Re: Enabling ImgBot in jenkinsci and in jenkins-infra/jenkins.io?

[Liam Newman]

It's not about size in the repo but size being served.  +1.

On Mon, Oct 7, 2019 at 8:25 AM Baptiste Mathus 
wrote:

> I'm a bit unconvinced this really changes the situation given things are
> still versioned and kept in the repo history, but still +1 why not! :)
>
> Le lun. 7 oct. 2019 à 10:09, Oleg Nenashev  a
> écrit :
>
>> Hi all,
>>
>> I would like to enable ImgBot in
>> some of my plugins in order to optimize image sizes. ImgBot is a bot which
>> creates pull requests with image optimizations, e.g. here is a sample pull
>> requests for the Jenkins Core:
>> https://github.com/oleg-nenashev/jenkins/pull/38. There are a lot of
>> historical images in Jenkins, and it could be a good opportunity to
>> optimize them.
>>
>> There is a free open-source plan for ImgBot, so I think enabling the bot
>> should not be a problem. As for other bots, I suggest we enable it in the
>> org but do not enable it widely by default. Each plugin maintainer will be
>> able to enable it on his/her own.
>>
>> What do you think?
>>
>> Thanks in advance,
>> Oleg
>>
>> --
>> 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/CAPfivLDM57J9zbP-MKrvQ64R%3Dm5xKLu%2BY235WM41NUYkr6EEQw%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/CAPyTVp3wet6VecECQqZDLAiTOHERfuPXsZ%2BhpNDLefDxS8tr6w%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/CAA0qCNzD7ooPvwZjher7JpJeN3taAfhg1qkiQXABhWZ0CepGzA%40mail.gmail.com.

Declarative Pipeline v1.4.0-beta-1 - Matrix stages

[Liam Newman]

Hello all!

I'm pleased to announce the release of Declarative Pipeline 1.4.0-beta-1 
with Matrix Stages. This feature allows pipeline authors to specify a 
matrix of one or more dimensions and run a set of stages on the combination 
of values specified. 

One simple use case where Matrix Stages are valuable is running browser 
tests on several operating systems and browser combinations.  Let’s say we 
want to run tests on Linux, OS X, and Windows for browsers Chrome, Firefox, 
IE, and Safari. We’ll want to run tests for IE on Windows only and we’ll 
want tests for Safari to run on OS X and Windows.  Here’s what that 
scenario will look like using the new “matrix” directive:

Jenkinsfile

--

pipeline {

agent none

stages {

stage("foo") {

matrix {

axes {

axis {

name 'os'

values "linux", "windows", "mac"

}

axis {

name 'browser'

values "firefox", "chrome", "safari", "ie"

}

}

excludes {

exclude {

axis {

name 'os'

values 'linux'

}

axis {

name 'browser'

values 'safari'

}

}

exclude {

axis {

name 'os'

notValues 'windows'

}

axis {

name 'browser'

values 'ie'

}

}

}

stages {

stage("first") {

steps {

echo "Running on OS=$os, BROWSER=$browser"

}

}

stage("second") {

steps {

// ... Second stage steps ... 

}

}

}

}

}

}

}

--

In the example, we specify two axes and the values for each of them. Then, 
we use the optional “excludes” directive to remove undesired combinations 
from the matrix. Finally, we specify one or more stages that we want to run 
on each combination.   

Log fragment:

…

[Pipeline] stage

[Pipeline] { (foo)

[Pipeline] parallel

[Pipeline] { (Branch: Matrix: os = 'linux', browser = 'firefox')

[Pipeline] { (Branch: Matrix: os = 'windows', browser = 'firefox')

[Pipeline] { (Branch: Matrix: os = 'mac', browser = 'firefox')

[Pipeline] { (Branch: Matrix: os = 'linux', browser = 'chrome')

[Pipeline] { (Branch: Matrix: os = 'windows', browser = 'chrome')

[Pipeline] { (Branch: Matrix: os = 'mac', browser = 'chrome')

[Pipeline] { (Branch: Matrix: os = 'windows', browser = 'safari')

[Pipeline] { (Branch: Matrix: os = 'mac', browser = 'safari')

[Pipeline] { (Branch: Matrix: os = 'windows', browser = 'ie')

...



Declarative Pipeline 1.4.0-beta-1 is available from the experimental update 
center now (
https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/). 
I look forward to hearing what you think of this feature and what you’d 
like to see in future updates to Declarative Pipeline. 

Thanks,

Liam Newman 

Senior Software Engineer - Pipeline 

-- 
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/78b8f8e6-b61c-49dc-ba24-9d25f0baa825%40googlegroups.com.

Re: Accessing PR head commit sha from a pipeline using branch source plugin

[Liam Newman]

Yes, you should absolutely create a JIRA. 

On Tuesday, July 2, 2019 at 8:46:42 AM UTC-7, Julien HENRY wrote:
>
> Hi Jesse,
>
> Here are 3 PRs to implement the proposed change. I did only Bitbucket so 
> far, but if you confirm I'm on the good track, I will submit the same for 
> GitHub (I have the changes locally, just haven't tested end-to-end).
> https://github.com/jenkinsci/scm-api-plugin/pull/71
> https://github.com/jenkinsci/branch-api-plugin/pull/163
> https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/206
>
> I think having a JIRA ticket to refer would be great, should I create one?
>
> I'm open to discussion to improve the code, either on this thread or on 
> PRs themselves.
>
> ++
> Julien Henry | SonarSource
>
> Developer
> https://sonarsource.com
>
>
> Le jeu. 13 juin 2019 à 15:44, Jesse Glick  > a écrit :
>
>> On Thu, Jun 13, 2019 at 8:53 AM Julien HENRY
>> > wrote:
>> > the GIT_COMMIT variable […] was not defined out of the box in my tests. 
>> I had to get it from the return of the checkout step
>>
>> Yes, each `checkout` step in the build, of which there could be zero
>> or more, can return its own metadata.
>>
>> For a branch project (such as a build of a GH PR),
>> `BranchNameContributor` sets build-wide environment variables
>> corresponding to the revision associated with the build overall. This
>> is what you would get if you `checkout scm`.
>>
>> -- 
>> 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/-ojqklsaKbw/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 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2d5Uawmzr-ybfbFjL8jNorY03NZ2Gjc2uoi0YyFxT-Ww%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/351ae677-0527-4069-9bef-9fde13f64762%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for copy-editor permissions for github.com/jenkins-infra/jenkins.io

[Liam Newman]

Absolutely +1.  Surprised you don't already have it.

On Thu, Jun 6, 2019 at 5:23 PM Rick  wrote:

> +1 from me
>
> On Fri, Jun 7, 2019 at 7:25 AM Alyssa Tong  wrote:
>
>> +1 from me as well. Tracy's help will help to move the PRs along as we've
>> experienced a little bit of a traffic jam :o)
>>
>> On Thu, Jun 6, 2019 at 1:34 PM Mark Waite 
>> wrote:
>>
>>> +1 from me.
>>>
>>> On Thu, Jun 6, 2019 at 2:32 PM Tracy Miranda 
>>> wrote:
>>>
 Hi all,

 From https://issues.jenkins-ci.org/browse/INFRA-2138

 I would like to request to be part of the copy-editors group and have
 merge permissions for github.com/jenkins-infra/jenkins.io so as to
 help improve the velocity for prs on that repo as well as extra bandwidth
 for the existing team.


 Over the last year I have written 5-6 blog posts for jenkins.io:
 https://jenkins.io/blog/authors/tracymiranda/

 And I've provided reviews for other blog posts/website updates on a
 number of occasions, e.g.
 https://github.com/jenkins-infra/jenkins.io/pull/2214#issuecomment-488153007

 As well as updates to other pages or assisting others get content into
 the blog format

 https://github.com/jenkins-infra/jenkins.io/pull/2135

 https://github.com/jenkins-infra/jenkins.io/pull/2105


 Regards,

 Tracy

 --
 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/CACTaz6r6ufD5Z7%2BqmE%2BPauH2a9PXPi2VueTYKSRV007-pGML7g%40mail.gmail.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>> --
>>> Thanks!
>>> Mark Waite
>>>
>>> --
>>> 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/CAO49JtGvXSbY%3Du3yDeENH5BprNWGeKGtpW8CkMheUqkhhi%3DpVg%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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/CAC9wNawvK1vBXnamizY0BhZadGgaQSYrEJgaD-1kKu6LD4QeOg%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
> --
> 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/CAMM7nTEEK_7V0Hk-mSOO1x_JTxgM3aM8eqWsLWB7xSxMp79xQQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNyU1eVSV95c3dNQCXwLfGD9OOUzTvEuOE75Ohgpat_EMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking information about GitHub Branch Source Plugin

[Liam Newman]

Parichay,
I look forward to seeing what you come up with.
-L.


On Mon, May 20, 2019 at 5:29 AM Parichay Barpanda <
parichay.barpa...@gmail.com> wrote:

> Thanks Robert.
>
> I checked the Gitea Plugin. It seems like the most recently developed
> plugin among other Branch Source Plugins like GitHub and BitBucket.
>
> My first impressions:
>
> It has a cleaner codebase because it was inspired from other Branch Source
> Plugins and removed the legacy support?
>
> I can find this plugin handles everything related to Gitea which is auth,
> webhooks, APIs, build triggers and Branch Source functions. My plan for
> GitLab Branch Source Plugin is to follow the convention of GitHub Branch
> Source Plugin i.e. a suite of 3 plugins, namely
>
> 1) GitLab API plugin,
>
> 2) GitLab plugin and
>
> 3) GitLab Branch Source Plugin.
>
> The reason behind it is:
>
> 1) removes a potential user confusion as major SCM plugins (GitHub /
> BitBucket) follow (or will follow) this rule
>
> 2) avoid code duplication as `GitLab Plugin` exists which does everything
> except Branch source functions.
>
> Although immaterial in this case because I can create a subset out of the
> Gitea Plugin to create the GitLab Branch Source Plugin. It would be
> interesting to note what would the differences in implementation look like.
>
> I'll take sometime to read the Gitea Plugin codebase and come up with a
> clear distinction.
>
> Btw design document for GitLab Branch Source Plugin is in the making. It
> should be ready this week.
>
> In case you want to take a look at the partial implementation of it, here
> you go:
>
>
> https://docs.google.com/document/d/1r_zQy5KpNNAO4KerFJrowWvGfFIU7xdEdqKgFenS3lI/edit?usp=drivesdk
>
> Thanks.
>
> Regards,
> Parichay (baymac)
>
> On Mon 20 May, 2019, 17:03 Robert Sandell,  wrote:
>
>> I'd suggest you first take inspiration from the Gitea plugin
>> , last time I checked it had
>> the most clean branch-api implementation. GitHub Branch Source and
>> Bitbucket Branch Source are suffering from a couple of branch-api/scm-api
>> generations of rewrites that can "muddy the waters a bit" when looking at
>> writing a new plugin :)
>>
>> /B
>>
>> Den sön 19 maj 2019 kl 18:19 skrev Parichay Barpanda <
>> parichay.barpa...@gmail.com>:
>>
>>> Thanks batmat for the answers.
>>>
>>> On Sun 19 May, 2019, 21:27 Baptiste Mathus,  wrote:
>>>


 Le mer. 15 mai 2019 à 22:17, Parichay Barpanda <
 parichay.barpa...@gmail.com> a écrit :

> Hi all,
>
> I was reading the GitHub Branch Source Plugin documentation here -
> https://go.cloudbees.com/docs/plugins/github-branch-source/ trying to
> take some inspiration from *GitHub Branch Source Plugin* for a
> similar *GitLab Branch Source Plugin*.
>
> Here are a few questions I would like to ask:
>
> 1) An excerpt from the GitHub PR section:
>
>  “Pull requests will be added to Jenkins as long as the pull request
> originates from a remote repository, contains a Pipeline script in a
> Jenkinsfile, and is mergable.
> *Even when you make changes to your Jenkinsfile, the checked out code
> is at the revision as the script.*”
>
> What does the last line mean?
>

 Not sure TBH.


> 2) While running a GitHub folder organisation on my GitHub Account,
> build log shows the following:
>
> “...*19:25:39 GitHub API Usage: Current quota has 51 remaining (2
> over budget). Next quota of 60 in 59 min. Sleeping for 6 min 48 sec*.”
>
> And the build simply pauses. What is the possible issue here?
>

 Not an issue. More a feature IIUC your question.
 GitHub API has a quota. So if you hammer it too much, your code will
 simply start failing (and it did).
 So like 1 year ago, the code was optimized (thanks Stephen and
 CloudBees sponsoring this) to do less calls and to introduce waits when
 quota was about to be reached.

>
> 3) Are there any important additions made to the plugin since the
> documentation was written? A list of classes would also do, I specifically
> want to look at their codes.
> I can find some UI changes in behaviours (recent plugin wrt
> documentation pictures), don't see the folder computation option etc.
> Looking for any interesting changes which can be leveraged by new Branch
> Source Plugins?
>

 Not sure for this. I'd recommend you check PRs since then and check how
 much/if docs were added alongside code additions. And don't hesitate to ask
 for clarifications in these merged PRs to be able to possibly file related
 docs PRs.

 Thanks!

>
> Thanks.
>
> Regards,
> Parichay (baymac)
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails 

Re: Multibranch pipeline overwrite GIT_COMMIT when merges the master branch

[Liam Newman]

I'm doing some work in this area.  I think I can guess the problem: 

... so we make groups and launch a downstream job for each group, at this 
point all OK, the problem starts when you try to pass the GIT_COMMIT
to the downstream job if the master branch has changed ...

For a merge job on a PR, GIT_COMMIT is going to be either the head commit 
of the source branch (as you noted) or it is going to be the _local_ merge 
commit on that machine which definitely won't exist in in the repository.  

Further, GIT_PREVIOUS_COMMIT is the commit that was run for the previous 
execution of that job on that agent, so if it was a local merge it is also 
not going to be in the repository.

I understand your desire to pin the commit on the downstream jobs to match 
pipeline, but in the case of merge jobs there isn't a simple solution to 
achieve that reliably at this time.  Please file a Jenkins JIRA issue with 
this information so we can think about this scenario.  I'm not sure how 
we'd address this but that is a longer discussion.  

A couple of possible workarounds/mitigations come to mind: 
1. Use git to get the values yourself - as the first stage in your 
pipeline, run some git commands in a shell on an agent. These commands 
would get the head commits from the base and pr branches.  Load that 
information into variables, something like "GIT_BASE_COMMIT" and 
"GIT_PR_COMMIT".  Then pass those values into your downstream jobs and 
merge there.  This would be quite a bit of hacking, but it could work.  (I 
don't know what the scripts would look like off the top of my head, but I'm 
sure they are doable). 

2.  Use head ("current pull request revision" strategy) to build your PRs 
instead of merge - this is less than ideal, but it would get you stable 
builds that don't mutate out from under you. 

3. Alternately, as the first stage in your build you could create a merge 
and push it to a branch, something like "jenkins/pr-352/",  
then you could pass that branch to your downstream jobs and be confident 
that they wouldn't change.  It would however mean that your Jenkins would 
need push access to your repo. 

None of these are what I would call "good" workarounds, but they would 
unblock you within your current design and the current Jenkins behavior.  
Definitely file a JIRA and we can delve further there into how this 
scenario would be better addressed in the future. 

Liam Newman 
CloudBees Pipeline Team



On Thursday, February 28, 2019 at 12:18:29 PM UTC-8, Ivan Fernandez Calvo 
wrote:
>
> Hi,
>
> We use multibranch pipelines for our project, it works pretty well and it 
> is nice to have PRs tested merged with the master branch, we also use 
> Blueocean for our UI, and here we have to use a workaround to make our UI 
> user-friendly.
> Our jobs spin 100-150 test in parallel, BO is not really user-friendly 
> with that amount of parallel stages so we make groups and launch a 
> downstream job for each group, at this point all OK, the problem starts 
> when you try to pass the GIT_COMMIT
> to the downstream job if the master branch has changed when the checkout 
> make the merge, the resulting commit (GIT_COMMIT env variable) is not in 
> the repo,so the downstream job cannot checkout the GIT_COMMIT and it fails. 
> I can pass the GIT_BRANCH but I'd prefer to pass the commit sha1. I start 
> to play with `git rev-list HEAD -4` and `git reflog -6` to see if always 
> have the same pattern and try to grab the correct commit sha1, but I start 
> thinking that should be a better way. 
> Also, I can disable the merge and make it on the downstream job but I 
> don't like it either. WDYT?
>
> GIT_PREVIOUS_COMMIT also point to an existing commit so I cannot use it.
>
> In this example, the PR head commit is 
> `08da92d31512c4a0c24948bc80f911f83c075070`, but GIT_COMMIT points 
> to'7c36975a772dbab59e20169a0ac01e60fb6db739' and GIT_PREVIOUS_COMMIT to 
> '6cd1da59add5d188cad41b9cbdcd33f4a7241c63' none of those in the repo
>
> ```
> using credential token
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://github.com/org/repo.git # 
> timeout=10
> Fetching without tags
> Fetching upstream changes from https://github.com/org/repo.git
>  > git --version # timeout=10
> using GIT_ASKPASS to set credentials GitHub user @elasticmachine User + 
> Personal Access Token
>  > git fetch --no-tags --progress https://github.com/org/arepo.git 
> +refs/pull/352/head:refs/remotes/origin/PR-352 
> +refs/heads/master:refs/remotes/origin/master
> Merging remotes/origin/master commit 
> e067dce0923be39f9b48e721240cf26ee083ab9e into PR head commit 
> 08da92d31512c4a0c24948bc80f911f83c075070
>  > git config core.sparsecheckout # timeout=10
&g

Re: A new home for Jenkins

[Liam Newman]

Hello everyone!

We'll be doing an online Q on this tomorrow:
January 23rd, 2019 - 10am PST (6pm UTC)
Zoom: https://zoom.us/j/165732888 
Here's a link to the Google calendar event 


Please join us and bring any questions you might have. 




On Thursday, January 17, 2019 at 3:02:09 PM UTC-8, Kohsuke Kawaguchi wrote:
>
>
> On Thu, Jan 17, 2019 at 12:26 AM nicolas de loof  > wrote:
>
>> That's a great new imho. This is not just about getting Jenkins community 
>> find a legal status. This is about building a full ecosystem and get 
>> collaboration with many other tools and vendor in this area. I remember the 
>> CNCF announcement, which was a tiny thing, and became a fantastic 
>> ecosystem. I hope CDF will bring the same dynamic.
>>
>
> Right, that's the goal. My hope is that the broad term that is "Continuous 
> Delivery" creates a big enough umbrella for enough projects and the 
> communities to work together. Also, these OSS projects working better 
> together is beneficial for user organizations, and that's how we hope to 
> drive more participations.
>
>  
>
>> Le jeu. 17 janv. 2019 à 07:49, Rick > a 
>> écrit :
>>
>>> This would be huge good news for Jenkins community I think. Especially 
>>> for Jenkins China Community. I'm very looking forward to it. I think the 
>>> CDF could provide us with a great opportunity to host more events or 
>>> activities. I can image that CDF will help to bring more contributors and 
>>> sponsors into the community.
>>>
>>> Second, I need to thank KK for giving me the support and delegation to 
>>> running Jenkins Subscription WeChat Account. Now we almost have 1K 
>>> subscribers. One article will be published per week. And I'm willing to 
>>> take the initiative to help build an activity Jenkins Community in China. 
>>> I'd love to the contact person in China for CDF or Jenkins if we need some 
>>> kind that people. I've serval Jenkins related talks at some conference or 
>>> meetup last year. I hope I could speak more topics to my forks this year. 
>>> My company (alauda.io) and other companies or communities (DevOpsDays) 
>>> are very supportive. I hope I could show up in the KubeCon in China this 
>>> year.
>>>
>>> If I understand correctly, we don't discuss the details in this thread. 
>>> But if everything is going well, then we might need to create a new 
>>> organization which named like CDF. An official website might be necessary 
>>> too. So, in my opinion, it will have lots of works are waiting for us. 
>>> Right?
>>>
>>> Anyway, I expect more and more good news about Jenkins. If there's 
>>> anything I can do for the Jenkins community. Just say it.
>>>
>>> Best regards,
>>> Rick (Zhao Xiaojie)
>>>
>>> On Thu, Jan 17, 2019 at 4:32 AM Oliver Gondža >> > wrote:
>>>
 Those are interesting news. Are we expecting to partner with existing 
 communities around existing CD projects as a part of CDF? Are some of 
 them on board with this vision or do we expect they will join us 
 provided this turns out to be the right way to go? My concern is the 
 “Continuous Delivery Foundation” feels pretty general and while getting 
 under the wings of Linux Foundation is an impressive recognition of 
 what 
 we have achieved, it would be unfortunate to make an impression of 
 claiming the whole field without wider consensus.

 On 16/01/2019 20.01, Marky Jackson wrote:
 > This is very exciting and welcoming!!!
 > 
 >> On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi >>>  
 >> > wrote:
 >>
 >> Ever since our project got our present ‘Jenkins’ name in 2011, we’ve 
 >> always been conscious about the governance of this project. It’s a 
 key 
 >> part of ensuring the well-being of the project. We’ve not only 
 talked 
 >> the talk, but done some walking the walk too, such as team 
 >> , JEP 
 >> , and SIG <
 https://jenkins.io/sigs/>.
 >>
 >> One idea in this space that we’ve discussed in and out is software 
 >> foundation around Jenkins. Those of you who came to Jenkins World 
 >> Contributor Summit in 2017 might remember Tyler presenting this idea 
 >> under the name “Jenkins Software Foundation” (see slides 
 >> <
 https://docs.google.com/presentation/d/1E3sUlRnfG-Dpmj-Lwrse56S0aUY3PBoGlenU5QwYCXg/edit#slide=id.g16abb2ffe7_0_242>
  

 >> and notes 
 >> <
 https://docs.google.com/document/d/1JSxYNI_RuA8ITlxVmxBdFg1A-sOKz-w7a9tzuPfWmr4/edit#heading=h.hc79wlk2cwzn>),
  

 >> at the DevOps World | Jenkins World Contributor Summit in 2018 and 
 >> afterwards, Tracy has helped continue this conversation (see slides 
 >> <
 

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[Liam Newman]

Marky, 

Are you saying you'd like to be one of the Leads for this SIG or just that 
you want to be a member of it? 

-Liam 

On Tuesday, December 18, 2018 at 12:01:05 PM UTC-8, Marky Jackson wrote:
>
> I would like to volunteer 
>
> On Dec 18, 2018, at 11:59 AM, Oleg Nenashev  > wrote:
>
> I noticed that I have forgot to respond to Liam's question about the SIG 
> leadership.
>
> As a separate question: Who are potential owners of the SIG(s)?
>>
>> Some candidates:
>>
>>    - Oleg Nenashev
>>- Tracy Miranda 
>>- Liam Newman
>>- (your name here - any voluteers?)
>>
>> No volunteers here so far (beyond the list by Liam). SIGs may actually 
> multiple leaders to balance the workload and to have more capacity (see 
> Roles in JEP-4 <https://github.com/jenkinsci/jep/tree/master/jep/4#roles>). 
> We did it for GSoC and Platform SIGs, and I believe it can work well here 
> as well. My proposal would be to just start the SIG with multiple leaders 
> (whomever is active in the Jenkins community && shows interest in it), and 
> then we can adjust going forward.
>
> P.S: Personally I am interested to participate in organizing this SIG, and 
> I will be happy to commit some time to this effort. I will have a very 
> limited availability over the next months due to personal reasons and GSoC, 
> but I will try to help where I can.
>
> Best regards,
> Oleg
>
>  
> On Wednesday, December 12, 2018 at 5:32:46 PM UTC+1, Oleg Nenashev wrote:
>>
>> Option 3 is my preference, but I am OK with options 1/2 as well
>>
>>
>> On Tue, Dec 11, 2018 at 11:22 PM Liam Newman > > wrote:
>>
>>> Oleg,
>>> I totally agree with how you described the SIG's relationship with 
>>> channels - there to help, not to specifically own/control the channels.
>>>
>>> As to naming:
>>>
>>>1. "Advocacy and Outreach"
>>>2. "Outreach and Advocacy"
>>>3. "Advocacy and Community Outreach"
>>>4. "Community Outreach and Advocacy"
>>>
>>>
>>> I've listed these in my order of preference, with my only -1 vote being 
>>> #4.   Anyone else have an opinion? 
>>>
>>> -L. 
>>>
>>> On Sunday, December 9, 2018 at 1:41:28 AM UTC-8, Rick wrote:
>>>>
>>>> In my opinion, anyone who wants to help advocacy the Jenkins could be 
>>>> part of the social media channels. Of course, the code of conduct is 
>>>> necessary. But how to running Twitter and WeChat or other social media 
>>>> channels. Maybe we could have a regular meeting to discuss.
>>>>
>>>> On Sun, Dec 9, 2018 at 3:16 PM Oleg Nenashev  
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I do not think that such activity needs to be transferred unless Rick 
>>>>> wants to do that. There are also many other outreach channels maintained 
>>>>> my 
>>>>> subprojects and other entities (e.g. Jenkins X, Evergreen, Jenkins RU, 
>>>>> etc., etc.). My understanding is that:
>>>>>
>>>>>- The SIG is interested to help others to create such channels (as 
>>>>>a part of outreach effort). E.g. it can help to create accounts and to 
>>>>>promote them in the community
>>>>>- The SIG does not claim ownership of the social media channels 
>>>>>unless it is agreed on
>>>>>
>>>>> Best regards,
>>>>> Oleg
>>>>>
>>>>> On Sun, Dec 9, 2018 at 1:52 AM Lloyd Chang  wrote:
>>>>>
>>>>>> Curiously, would specific localization initiatives (e.g. Chinese 
>>>>>> Localization SIG's WeChat) be transferred to the broader umbrella of 
>>>>>> Outreach and Advocacy Mega-SIG?
>>>>>>
>>>>>> For example: I view Twitter and WeChat as comparable mechanisms for 
>>>>>> advocacy; both would have measurable metrics re: followers and 
>>>>>> impressions.
>>>>>>
>>>>>> -- 
>>>>>>
>>>>> 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/84vjWz_Ho1k/unsubscribe
>>>>>> .
>>>>>> To unsub

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[Liam Newman]

Oleg,
I totally agree with how you described the SIG's relationship with channels 
- there to help, not to specifically own/control the channels.

As to naming:

   1. "Advocacy and Outreach"
   2. "Outreach and Advocacy"
   3. "Advocacy and Community Outreach"
   4. "Community Outreach and Advocacy"
   

I've listed these in my order of preference, with my only -1 vote being 
#4.   Anyone else have an opinion? 

-L. 

On Sunday, December 9, 2018 at 1:41:28 AM UTC-8, Rick wrote:
>
> In my opinion, anyone who wants to help advocacy the Jenkins could be part 
> of the social media channels. Of course, the code of conduct is necessary. 
> But how to running Twitter and WeChat or other social media channels. Maybe 
> we could have a regular meeting to discuss.
>
> On Sun, Dec 9, 2018 at 3:16 PM Oleg Nenashev  > wrote:
>
>> Hi,
>>
>> I do not think that such activity needs to be transferred unless Rick 
>> wants to do that. There are also many other outreach channels maintained my 
>> subprojects and other entities (e.g. Jenkins X, Evergreen, Jenkins RU, 
>> etc., etc.). My understanding is that:
>>
>>- The SIG is interested to help others to create such channels (as a 
>>part of outreach effort). E.g. it can help to create accounts and to 
>>promote them in the community
>>- The SIG does not claim ownership of the social media channels 
>>unless it is agreed on
>>
>> Best regards,
>> Oleg
>>
>> On Sun, Dec 9, 2018 at 1:52 AM Lloyd Chang > > wrote:
>>
>>> Curiously, would specific localization initiatives (e.g. Chinese 
>>> Localization SIG's WeChat) be transferred to the broader umbrella of 
>>> Outreach and Advocacy Mega-SIG?
>>>
>>> For example: I view Twitter and WeChat as comparable mechanisms for 
>>> advocacy; both would have measurable metrics re: followers and impressions.
>>>
>>> -- 
>>>
>> 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/84vjWz_Ho1k/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> jenkinsci-de...@googlegroups.com .
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/4e219e41-f579-4316-a382-0c7cf72bd55c%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCz0oyDmsKcmSz%2Biq9Sw0B6UQ%3DLqEdSYizYR8k-Uh4NuA%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/43bbbede-6538-482f-b49c-9ce207ab8cf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using Jenkins JIRA to record development priorities for a plugin?

[Liam Newman]

Awesome!

On Tue, Dec 11, 2018 at 9:39 AM Mark Waite 
wrote:

> I've taken one step further with the git plugin and the git client
> plugin.  I've created GitHub milestones
>
>- Git client plugin 3.0
><https://github.com/jenkinsci/git-client-plugin/milestone/1>
>- Git plugin 4.0 <https://github.com/jenkinsci/git-plugin/milestone/3>
>- Git client plugin "Later"
><https://github.com/jenkinsci/git-client-plugin/milestone/2?closed=1>
>(closed for now, intending to reopen once the higher priority reviews
>are resolved)
>- Git plugin "Later"
><https://github.com/jenkinsci/git-plugin/milestone/4?closed=1> (closed
>for now, intending to reopen once the higher priority reviews are resolved)
>
> The "Later" milestone includes pull requests that are closed for now.
> That reduces the load on the CI server continuously evaluating each pull
> request one each update to the master branch and records those pull
> requests which should be opened and evaluated after higher priority items
> are resolved.
>
> Mark Waite
>
> On Sun, Dec 9, 2018 at 7:45 PM Mark Waite 
> wrote:
>
>> Here are the results of my tagging:
>>
>>1. BuildData bloat
>><https://github.com/jenkinsci/git-plugin/labels/1%20-%20BuildData>
>>2. notifyCommit
>><https://github.com/jenkinsci/git-plugin/labels/2%20-%20notifyCommit>
>>3. Submodules
>><https://github.com/jenkinsci/git-plugin/labels/3%20-%20Submodules>
>>4. Caching
>><https://github.com/jenkinsci/git-plugin/labels/4%20-%20Caching>
>>5. Changelog
>><https://github.com/jenkinsci/git-plugin/labels/5%20-%20Changelog>
>>
>> Thanks for the suggestion.  We'll see how it works.
>>
>> Mark Waite
>>
>> On Sun, Dec 9, 2018 at 6:56 PM Mark Waite 
>> wrote:
>>
>>>
>>>
>>> On Sun, Dec 9, 2018 at 2:52 PM Liam Newman  wrote:
>>>
>>>> Mark,
>>>>
>>>> What about using labels in Github?  Since these are PRs you can add
>>>> whatever labels you want to them.
>>>>
>>>>
>>> Labels are an interesting idea, since the highest ranked items in my
>>> prioritization could be grouped into relatively few categories.  I may try
>>> that as an easy experiment rather than wrestling with JIRA.  The categories
>>> I'd use for now would be:
>>>
>>>- 1 - BuildData bloat
>>>- 2 - notifyCommit (slashes in branch names, etc.)
>>>- 3 - Submodules
>>>- 4 - Caching and performance
>>>- 5 - Changelog
>>>
>>> The digit at the start of the label indicates the priority, the word in
>>> the label indicates the topic.  Those 5 topics cover over 30% of the 60+
>>> open pull requests.  There is more work in those 5 labels than I will be
>>> able to complete in several years, so it is more than enough prioritization
>>> for my needs.
>>>
>>> Thanks for the suggestions.
>>> Mark Waite
>>>
>>>
>>>> Changing labels is tracked and visible, and I don't think
>>>> non-collaborators can change them.
>>>>
>>>>
>>>>
>>>> On Sunday, December 9, 2018 at 11:58:47 AM UTC-8, Stephen Connolly
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sun 9 Dec 2018 at 15:35, Mark Waite  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 9, 2018 at 8:18 AM Daniel Beck  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > On 9. Dec 2018, at 15:34, Mark Waite  wrote:
>>>>>>> >
>>>>>>> > Is it allowed to use issues.jenkins-ci.org for that type of
>>>>>>> tracking?
>>>>>>> >
>>>>>>>
>>>>>>> I don't see why it would not be, or do you need access to features,
>>>>>>> or plugins installed, that you currently don't have?
>>>>>>>
>>>>>>>
>>>>>> I am not aware of needing anything more than is already available to
>>>>>> me.  However, I haven't tried the experiment yet, so I'm not 100% 
>>>>>> certain.
>>>>>>
>>>>>>
>>>>>>> FWIW any user can reorder issues on boards ("rank"), or change their
>>>>>>> priority, so neither i

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[Liam Newman]

"... related.  I'd rather keep them together even with the scope being a 
bit broad."  
(don't know what happened there. CTRL-X misfire.)

On Wednesday, December 5, 2018 at 10:55:41 AM UTC-8, Liam Newman wrote:
>
> Oleg, 
> I understand your point that Outreach and Advocacy feel like separate 
> areas, but they are closely related.  However, I'd together even with the 
> scope being a bit broad.  
>
> I think that everyone in an Advocacy SIG would need to also be part of an 
> Outreach SIG - IMO a core aspect of advocacy for Jenkins is outreach.  To 
> some extent, I think calling the SIG "Advocacy and Outreach" is almost 
> redundant - except that, for the sake of new user outreach it is important 
> to specify "Outreach" in the name of the SIG. :) 
>
> Reversing that, people that are interested in working on Outreach and new 
> user experience will generally need to be involved in discussions around 
> Advocacy. We have sub-channels (and SIGs) for some outreach projects 
> already. 
>
> Does anyone else have strong feeling either way? 
>
> As a separate question: Who are potential owners of the SIG(s)?
>
> Some candidates:
>
>- Oleg Nenashev
>- Tracy Miranda 
>- Liam Newman
>- (your name here - any voluteers?)
>
>
> Thanks,
> Liam N. 
>
> On Monday, December 3, 2018 at 11:03:16 PM UTC-8, Oleg Nenashev wrote:
>>
>> My preference for structure would be as 1 SIG (called Outreach or 
>>> Outreach & Advocacy) which is an umbrella for initiatives like GSoC, 
>>> Outreachy, Hacktoberfest. 
>>>
>>
>> I definitely agree with such scope if it is an "Outreach" SIG.
>> But I do not see a lot of "Advocacy" in this scope TBH (Wikipedia 
>> <https://en.wikipedia.org/wiki/Advocacy>).
>>
>>1. We do not manage social media
>>2. We do not work with Jenkins Ambassadors
>>3. This SIG does not coordinate JAMs, JOMs and other similar events
>>4. ... // whatever other stuff from the first message (scope is 
>>definitely bloated there)
>>
>> Please correct me if I am wrong.
>>
>> Liam, your proposal was to actually have an Advocacy SIG IIRC. If we go 
>> forward with the Outreach SIG, we still might create an Advocacy SIG. How 
>> do you see it?
>>
>> Best regards,
>> Oleg
>>  
>> On Tuesday, December 4, 2018 at 1:19:39 AM UTC+1, Liam Newman wrote:
>>>
>>> I'm also plus +1, Tracy.
>>>
>>> I'm a little concerned about over-broad scope.  But was can always 
>>> adjust it as we go along. 
>>>
>>>
>>> On Monday, December 3, 2018 at 8:49:35 AM UTC-8, R Tyler Croy wrote:
>>>>
>>>> (replies inline) 
>>>>
>>>> On Mon, 03 Dec 2018, Tracy Miranda wrote: 
>>>>
>>>> > This sounds great. 
>>>> > 
>>>> > My preference for structure would be as 1 SIG (called Outreach or 
>>>> Outreach 
>>>> > & Advocacy) which is an umbrella for initiatives like GSoC, 
>>>> Outreachy, 
>>>> > Hacktoberfest. 
>>>> > 
>>>> > GSoC, Outreachy should maintain their own channels i.e. gitter, etc 
>>>> so 
>>>> > those who want to just focus on those can do so. But then at the SIG 
>>>> level 
>>>> > we cover more topics (as listed in the email) share best practices 
>>>> and 
>>>> > foster wider collaboration across initiatives for those who would 
>>>> like to 
>>>> > do so. 
>>>>
>>>>
>>>> This sounds good to me Tracy, +1 
>>>>
>>>>
>>>> -- 
>>>> GitHub:  https://github.com/rtyler 
>>>>
>>>> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 
>>>>
>>>

-- 
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/6f927b51-ec35-423c-abda-21e7976b0d41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[Liam Newman]

Oleg, 
I understand your point that Outreach and Advocacy feel like separate 
areas, but they are closely related.  However, I'd together even with the 
scope being a bit broad.  

I think that everyone in an Advocacy SIG would need to also be part of an 
Outreach SIG - IMO a core aspect of advocacy for Jenkins is outreach.  To 
some extent, I think calling the SIG "Advocacy and Outreach" is almost 
redundant - except that, for the sake of new user outreach it is important 
to specify "Outreach" in the name of the SIG. :) 

Reversing that, people that are interested in working on Outreach and new 
user experience will generally need to be involved in discussions around 
Advocacy. We have sub-channels (and SIGs) for some outreach projects 
already. 

Does anyone else have strong feeling either way? 

As a separate question: Who are potential owners of the SIG(s)?

Some candidates:

   - Oleg Nenashev
   - Tracy Miranda 
   - Liam Newman
   - (your name here - any voluteers?)
   
   
Thanks,
Liam N. 

On Monday, December 3, 2018 at 11:03:16 PM UTC-8, Oleg Nenashev wrote:
>
> My preference for structure would be as 1 SIG (called Outreach or Outreach 
>> & Advocacy) which is an umbrella for initiatives like GSoC, Outreachy, 
>> Hacktoberfest. 
>>
>
> I definitely agree with such scope if it is an "Outreach" SIG.
> But I do not see a lot of "Advocacy" in this scope TBH (Wikipedia 
> <https://en.wikipedia.org/wiki/Advocacy>).
>
>1. We do not manage social media
>2. We do not work with Jenkins Ambassadors
>3. This SIG does not coordinate JAMs, JOMs and other similar events
>4. ... // whatever other stuff from the first message (scope is 
>definitely bloated there)
>
> Please correct me if I am wrong.
>
> Liam, your proposal was to actually have an Advocacy SIG IIRC. If we go 
> forward with the Outreach SIG, we still might create an Advocacy SIG. How 
> do you see it?
>
> Best regards,
> Oleg
>  
> On Tuesday, December 4, 2018 at 1:19:39 AM UTC+1, Liam Newman wrote:
>>
>> I'm also plus +1, Tracy.
>>
>> I'm a little concerned about over-broad scope.  But was can always adjust 
>> it as we go along. 
>>
>>
>> On Monday, December 3, 2018 at 8:49:35 AM UTC-8, R Tyler Croy wrote:
>>>
>>> (replies inline) 
>>>
>>> On Mon, 03 Dec 2018, Tracy Miranda wrote: 
>>>
>>> > This sounds great. 
>>> > 
>>> > My preference for structure would be as 1 SIG (called Outreach or 
>>> Outreach 
>>> > & Advocacy) which is an umbrella for initiatives like GSoC, Outreachy, 
>>> > Hacktoberfest. 
>>> > 
>>> > GSoC, Outreachy should maintain their own channels i.e. gitter, etc so 
>>> > those who want to just focus on those can do so. But then at the SIG 
>>> level 
>>> > we cover more topics (as listed in the email) share best practices and 
>>> > foster wider collaboration across initiatives for those who would like 
>>> to 
>>> > do so. 
>>>
>>>
>>> This sounds good to me Tracy, +1 
>>>
>>>
>>> -- 
>>> GitHub:  https://github.com/rtyler 
>>>
>>> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 
>>>
>>

-- 
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/02b0a0fc-224c-46da-b137-ddbea3738e5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[Liam Newman]

I'm also plus +1, Tracy.

I'm a little concerned about over-broad scope.  But was can always adjust 
it as we go along. 


On Monday, December 3, 2018 at 8:49:35 AM UTC-8, R Tyler Croy wrote:
>
> (replies inline) 
>
> On Mon, 03 Dec 2018, Tracy Miranda wrote: 
>
> > This sounds great. 
> > 
> > My preference for structure would be as 1 SIG (called Outreach or 
> Outreach 
> > & Advocacy) which is an umbrella for initiatives like GSoC, Outreachy, 
> > Hacktoberfest. 
> > 
> > GSoC, Outreachy should maintain their own channels i.e. gitter, etc so 
> > those who want to just focus on those can do so. But then at the SIG 
> level 
> > we cover more topics (as listed in the email) share best practices and 
> > foster wider collaboration across initiatives for those who would like 
> to 
> > do so. 
>
>
> This sounds good to me Tracy, +1 
>
>
> -- 
> GitHub:  https://github.com/rtyler 
>
> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 
>

-- 
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/a8699b87-be0b-4418-abea-7f356c5d98ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding audit logs to Jenkins

[Liam Newman]

Matt,

Have you considered make a JEP for this effort?  It seems like something
that would benefit from having a design document that captures how the
design was arrived at and what alternatives were considered.

-Liam N.

On Mon, Oct 15, 2018 at 2:28 PM Matt Sicker  wrote:

> I've started tasking out this as an epic:
> https://issues.jenkins-ci.org/browse/JENKINS-54082
>
> On Mon, Jul 30, 2018 at 10:38 AM Matt Sicker 
> wrote:
>
>> On Wed, Jul 25, 2018 at 6:03 PM Daniel Beck  wrote:
>>
>>> Doesn't that just mean the listeners need to improved?
>>>
>>
>> Either way, that would require core changes.
>>
>>
>>> Do you have specific examples?
>>>
>>
>> Not offhand, though when I take a look at this again, I'll write up some
>> examples.
>>
>>
>> --
>> Matt Sicker
>> Software Engineer, CloudBees
>>
>
>
> --
> Matt Sicker
> Software Engineer, CloudBees
>
> --
> 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/CAEot4ox4soNv29ARgfRrzDZeWq%2Bx7BXA5hk5p39tFX%2BNzrNsBg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNy7WKOi4oJfh_kV5kMeiRFP2y_hAsg%2Bg-TX4uYrd98WJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Pipeline Authoring SIG

[Liam Newman]

Andrew,

Thanks for taking the lead on this. 

As noted, I'm eager to talk about documenting pipeline, but talking more 
about best practices and public examples.  One example would be, 
github.com/mozilla/fxapom (and the related shared library).  I'll loop the 
maintainers of that into this thread.  

-L.

On Monday, October 15, 2018 at 2:12:13 AM UTC-7, Andrew Bayer wrote:
>
> I’d like to propose the creation of a “Pipeline Authoring” SIG, with 
> myself as the lead. The focus of this SIG would be on improving all aspects 
> of the user experience around authoring Jenkins Pipeline. This includes: 
> * Syntax and structure
> * Extensibility, code reuse, and code sharing
> * Testability
> * Documentation
> * Tooling for Pipeline authors (like Snippet Generator, Directive 
> Generator, IDE integration, etc)
> * Best practices (including tooling for gentle nudges in the direction of 
> best practices)
> * Examples/"starter Jenkinsfiles" for various scenarios, etc
>
> While at Jenkins World I was able to discuss this idea with a number of 
> people.  Response was universally positive. Here are a few examples:
>
> * Steven Terrana (from Booz Allen) has done work on code sharing and reuse 
> in (https://github.com/boozallen/sdp-pipeline-framework) and is 
> interested in making some form of that available to the Jenkins community. 
> * Austin Witt (from HomeAway) has created on a groovy testing framework 
> for Jenkins Pipeline (https://github.com/homeaway/jenkins-spock/) 
> * Liam Newman (from CloudBees) has written and edited quite a bit of 
> documentation for  Jenkins Pipeline and provided feedback on the design on 
> a number of Pipeline feature.  He expressed a desire to continue expanding 
> and improving on that documentation.
> * And Kohsuke basically demanded that we do this. =) 
>  
> While this is not a large group, it was enough to convince me that this is 
> an area that deserve a SIG. There is strong interest from a number of 
> people  number and the area is also not covered by existing SIGs. 
>
> If you’d like to be part of the initial group of participants, please 
> respond on this thread. Other feedback and suggestion are also welcome. I 
> will create the appropriate SIG pages and channels in a few days.  We can 
> start figuring out where to focus our efforts first and can schedule the 
> group’s regular meetings to start some time after DevOps World - Jenkins 
> World in Nice <https://www.cloudbees.com/devops-world/nice>.
>
> A.  
>
>

-- 
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/9c3d4ec0-0c98-4cc0-91d6-dd9db08c42f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Jenkins as an umbrella org for its upstream components

[Liam Newman]

Oleg, 
I agree that having projects that jenkins depends deeply on sitting in 
personal repo's is not great.  Offering or asking the owners of those 
projects the option to bring their project into the project umbrella makes 
sense. 

I see in your doc that part of the intent of having a separate org is to 
let maintainers of those project retain some control, even having a process 
for a project to leave the jenkins-contrib org.  Is that is even an 
interesting scenario to the owners of project you are thinking of?  We 
might be addressing a non-issue.

Maybe there's a more general discussion to be had around whether the github 
org structure is the place to express overall project structure and if so 
what that structure should be. I could see how it would make sense to have 
an org that would hold jenkins adjacent projects such as "stapler", to 
maintain the clarity around which project could be used separately from 
jenkins.  

I added a couple suggestions to the doc as placeholders for further 
discussion. 

On Wednesday, October 10, 2018 at 7:22:41 AM UTC-7, Jesse Glick wrote:
>
> On Wed, Oct 10, 2018 at 7:13 AM Oleg Nenashev  > wrote: 
> > The governance model and hosting processes are slightly different from 
> lugins. 
>
> Sure, but that is also true of 200+ repos in `jenkinsci` today, and we 
> manage somehow. 
>
> > it may be tricky for external contributors to distinguish what is 
> Jenkins-only and what is available to be used outside 
>
> A big notice in `README.md`? Availability on Maven Central? 
>
> > We already have hundreds of repos in the Jenkins org, and it's not good 
> for visibility of "contrib" projects 
>
> Why is it more important for, say, `file-leak-detector` to have high 
> visibility than, say, `job-dsl-plugin`? And what makes you think a new 
> small GH org provides additional visibility, as opposed to the obvious 
> things like blog posts and tweets and search-engine-friendly links 
> from prominent documents? 
>

-- 
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/2b86a321-6787-472f-9e94-585cd95788ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JEP for Enhanced Travel Grant Proposal

[Liam Newman]

JEP-12 has been set to draft

I'd like to see this JEP describe the full travel program rather than the 
addendum. I've opened https://github.com/jenkinsci/jep/pull/206 to do 
this.  If it is merged, I'll update the wiki page to point to the JEP. 




On Sunday, September 16, 2018 at 1:34:33 PM UTC-7, Tracy Miranda wrote:
>
> My understanding is that the default $500 are able to be approved via 
> mailing list requests and votes (at least I've seen evidence of voting on 
> this in ml), and this is good as can happen asynchronously to governance 
> meetings which are bi-weekly. 
> So from that respect the proposal that anything above this amount & that 
> requires a thoughtful conversation should happen in a governance meeting. 
>
> Tracy
>
>
>
> On Sun, Sep 16, 2018 at 3:36 PM, Oleg Nenashev  > wrote:
>
>> According to the current wording, Governance meeting approval is needed 
>> only for requests above 500USD.
>> But then there is no clarity for requests below 500 USD. Do they get 
>> approved automatically? Or what is the process?
>>
>> BR, Oleg
>>
>> On Friday, September 14, 2018 at 4:59:44 PM UTC-7, Rick wrote:
>>>
>>> +1
>>>
>>> On Sat, Sep 15, 2018 at 12:02 AM Tracy Miranda  
>>> wrote:
>>>
 Hi all,

 Following on from discussions at a past Governance meeting[1] I have 
 created a JEP that proposes enhancements to the Travel Grant program. 
 Please take a look at the PR here 
 https://github.com/jenkinsci/jep/pull/202 and any feedback will be 
 welcome. 

 Regards,
 Tracy



 http://meetings.jenkins-ci.org/jenkins-meeting/2018/jenkins-meeting.2018-08-01-18.00.log.html

 -- 
 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-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6p_q65nUX9iYvtoZk7FTGpJdFMe%2BDWxd1Y7cegWKy3shw%40mail.gmail.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/462c5bf2-47a4-46ec-aeb0-1b7a1be91e2f%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/30b676a5-2167-4d49-8269-d57f9c736ca5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request permission for plugins

[Liam Newman]

I've made this JEP-216 Draft so that it can be referenced in discussions 
and form the prototype, but as noted it needs quite a bit of work.  

On Tuesday, August 28, 2018 at 7:01:57 AM UTC-7, Daniel Beck wrote:
>
>
>
> > On 28. Aug 2018, at 15:10, Oleg Nenashev  > wrote: 
> > 
> > I can imagine a local company which installs a single localization 
> plugin 
> > That's why I lean towards having separate plugins for each locale. 
>
> … and an aggregator. It's free. Only needs updates whenever a locale 
> plugin is added or removed. I really don't understand the resistance here. 
>
> > Depends on the installation logic implementation, but generally "yes". 
>
> Which installation logic would you consider to be supported (i.e. we 
> wouldn't close a related Jira issue immediately) and does not install 
> whatever is available on your chosen update site? CLI command, UI, even 
> install-plugins.sh and configuration-as-code plugin install the newest 
> available release of dependencies. 
>
>

-- 
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/8a4cc4fa-0eb6-43d3-8571-77b4dac2805c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Liam Newman]

Oleg,
+1 for cleanup, definitely.  The path you propose overall sounds good to 
me. 

On Thursday, September 6, 2018 at 6:40:23 AM UTC-7, Oleg Nenashev wrote:
>
> Obviously, step (5) is a bad idea then. Could we just have 2 repos without 
> "fork" relations then?
> If the codebase is not shared, it would help.
>
> As you can guess I have my strong opinion about classloader voodoo in KK's 
>> approach to a jenkinsfile-runner CLI.
>>
> Fine for PoC IMHO. It improves performance, and it may be useful in cases 
> when we want to have fast builds with really short initialization times. I 
> was doing some performance hacks for similar purposes a while ago (actually 
> some even weirder hacks). Obviously, a final implementation should not be 
> based on Jenkins Test Harness and JenkinsRule, some Jenkins core patches 
> will likely be needed.
>
>
> On Thu, Sep 6, 2018 at 3:31 PM nicolas de loof  > wrote:
>
>> please note ndeloof/jenkinsfile-runner is a complete different design vs 
>> KK initial prototype
>> they don't share architecture nor git history (only few java classes)
>>
>> so you'll have to choose one approach over the other
>>
>> As you can guess I have my strong opinion about classloader voodoo in 
>> KK's approach to a jenkinsfile-runner CLI.
>>
>> Le jeu. 6 sept. 2018 à 15:27, Baptiste Mathus > > a écrit :
>>
>>> +1 for cleaning up. Like we recommend for plugins, it would be nice that 
>>> canonical repo location is more clearly the one under jenkinsci org
>>>
>>> Le jeu. 6 sept. 2018 à 15:24, Oleg Nenashev >> > a écrit :
>>>
 Hi all,

 It seems we have a splitbrain issue in this project.
 Currently there is the following fork tree:

- https://github.com/kohsuke/jenkinsfile-runner
   - https://github.com/ndeloof/jenkinsfile-runner
  - https://github.com/jenkinsci/jenkinsfile-runner
  
 Jenkinsfile Runner in Kohsuke's repo has the most number of stars + 
 there is a number of issues and pull requests. It makes the jenkinsci repo 
 unsearchable, and it can also confuse users looking for a place to report 
 issues / propose patches.

 I propose to do the following:

1. Remove https://github.com/jenkinsci/jenkinsfile-runner and 
evacute the branches somewhere
2. Move https://github.com/kohsuke/jenkinsfile-runner to jenkinsci 
org (yes, move, not fork)
3. Rename the current master branch to "kohsuke-master"
4. Reintegrate the current 
https://github.com/jenkinsci/jenkinsfile-runner state as a master 
branch
5. See if "master" and "kohsuke-master" can be merged

 WDYT?

 BR, Oleg

 On Wednesday, April 4, 2018 at 9:30:15 PM UTC+2, Kohsuke Kawaguchi 
 wrote:
>
> Ouch, that's a shame. It looked like an interesting project, I hope my 
> writing to you didn't trigger that.
>
> You say "stress builds and also to burn in our build agents" -- can 
> you elaborate on that? It sounds like you are trying to warm up a cache 
> or 
> something, but I'm not sure what that means in the context of builds.
>
> On Wed, Apr 4, 2018 at 11:15 AM Tom Shaw  wrote:
>
>> Hi Kohsuke,
>>
>> Thanks for getting in touch. I've had to remove that repo temporarily 
>> at the request of my former employer. It looks like we are trying to 
>> solve 
>> the same problem. I wanted to use jenkinless to stress builds and also 
>> to 
>> burn in our build agents. It's more of a convenience tool. Running the 
>> slave using docker in docker worked really well. I might try and turn 
>> this 
>> into an executable that can be stored in the repo alongside code. 
>>
>> Tom
>>
>>
>> On Wed, 4 Apr 2018, 00:19 Kohsuke Kawaguchi,  
>> wrote:
>>
>>> Hi, Thomas,
>>>
>>> Tyler passed me a link to your project 
>>> https://github.com/tomwillfixit/jenkinless, which is in a similar 
>>> space with my project of the day called Jenkinsfile Runner.
>>>
>>> I haven't studied your project carefully yet, but I already see some 
>>> interesting ingredients like memcached that I have no idea what you use 
>>> it 
>>> for :-)   I'd love to hear from you the philosophy & use cases that led 
>>> to 
>>> it. And I'd also love to hear what you think of Jenkinsfile Runner. I 
>>> think 
>>> we have similar interests here, are there any opportunity to 
>>> collaborate?
>>>
>>> On Thu, Mar 1, 2018 at 11:23 AM Kohsuke Kawaguchi  
>>> wrote:
>>>
 And of course I forgot to have the link to the project! 
 https://github.com/kohsuke/jenkinsfile-runner 


 On Thu, Mar 1, 2018 at 11:22 AM Kohsuke Kawaguchi  
 wrote:

> Jenkinsfile Runner is an experiment to package Jenkins pipeline 
> execution as a command line tool. The intend use 

JEP Office hours 2018-09-06

[Liam Newman]

Hello all,

At the last JEP office hours we discussed: 

   - 
   
   “Mission and Goal” JEPs and relation to SIGs
   - 
   
   Submitting JEP-206 for acceptance
   

The video from the last meeting can be seen here: 
https://youtu.be/J01iwJBvltQ 

I've cancelled today's office hours due to people traveling and being on 
vacation.  But I'll go ahead and ask now if anyone has topics they'd like 
raised in the next meeting.  

If so, please respond to this thread or add comments to the agenda here: 
https://docs.google.com/document/d/1gWyaJ189n1fKkJS33xdK80PTY1jp11Tg3tWsQtFdyck/edit?usp=sharing



Thanks,
Liam Newman

-- 
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/383b31d4-b85b-4e82-b32d-50d7fb806f70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JEP Office Hours 2018-08-16

[Liam Newman]

Jesse added "Nature of “Mission and Goal” JEPs and relation to SIGs" to the 
agenda, so we'll meet and discuss in about 15 minutes.
https://hangouts.google.com/hangouts/_/wgw37usslfhhzfmunvwmlvxq7ie


On Thursday, August 16, 2018 at 6:12:13 AM UTC-7, Mark Waite wrote:
>
> I don't have other questions.  I suggest canceling it as well.
>
> On Thu, Aug 16, 2018 at 3:34 AM Oleg Nenashev  > wrote:
>
>> I suggest cancelling it if there is no interest from others.
>> Last two weeks there were only Liam and me on the calls. I have a number 
>> of JEP process improvements I would like to discuss with other 
>> contributors, but I didn't have time to write-up the proposals. So I have 
>> no topics for the today's meeting.
>>
>> BR, Oleg
>>
>> On Thursday, August 16, 2018 at 2:47:25 AM UTC+2, Liam Newman wrote:
>>>
>>> Hello all,
>>>
>>> At the last JEP office hours we discussed ways to comment on and ask 
>>> questions about JEPs when there isn't a PR currently open. 
>>> We looked at making edits to add comments or annotations.  
>>>
>>> We also discussed a few other potential changes to the JEP process such 
>>> as https://github.com/jenkinsci/jep/pull/162.  That discussion is still 
>>> open.
>>>
>>> The video from the last meeting can be seen here: 
>>> https://youtu.be/ZvIKI3s6bfU
>>>
>>> Does anyone have topics they'd like to discuss in the JEP Office Hours 
>>> tomorrow? 
>>>
>>> If so, please respond to this thread or add comments to the agenda here: 
>>>
>>> https://docs.google.com/document/d/1gWyaJ189n1fKkJS33xdK80PTY1jp11Tg3tWsQtFdyck/edit?usp=sharing
>>>
>>> Thanks,
>>> Liam Newman
>>>
>>>
>>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2af83cdb-3ca6-4743-93cc-4042355f89f8%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/2af83cdb-3ca6-4743-93cc-4042355f89f8%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/84d75e39-d3bd-43b4-8320-c2d0ca181020%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

JEP Office Hours 2018-08-16

[Liam Newman]

Hello all,

At the last JEP office hours we discussed ways to comment on and ask 
questions about JEPs when there isn't a PR currently open. 
We looked at making edits to add comments or annotations.  

We also discussed a few other potential changes to the JEP process such 
as https://github.com/jenkinsci/jep/pull/162.  That discussion is still 
open.

The video from the last meeting can be seen 
here: https://youtu.be/ZvIKI3s6bfU

Does anyone have topics they'd like to discuss in the JEP Office Hours 
tomorrow? 

If so, please respond to this thread or add comments to the agenda here: 
https://docs.google.com/document/d/1gWyaJ189n1fKkJS33xdK80PTY1jp11Tg3tWsQtFdyck/edit?usp=sharing

Thanks,
Liam Newman


-- 
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/644080a3-62c8-479c-81ef-8d6f51553cab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Chinese Localization SIG

[Liam Newman]

I realize I'm late to this discussion, but could we make this the 
"Localization SIG". Having this be for one language alone seems a bit too 
narrow.

Obviously, the core focus you'd like to work on is Chinese, but the work 
done there will likely overlap with Localization to other languages. 

I'm open to discussion. 

Thanks,
Liam Newman


On Saturday, August 11, 2018 at 8:10:45 AM UTC-7, Rick wrote:
>
> Hi all,
>
>
> I made a list of plugins that will be foucsed in Localization SIG, like 
> below:
>
>
> *credentials-plugin <https://github.com/jenkinsci/credentials-plugin>*
>
> *plain-credentials-plugin* 
> <https://github.com/jenkinsci/plain-credentials-plugin>
>
> *ssh-credentials-plugin* 
> <https://github.com/jenkinsci/ssh-credentials-plugin>
>
>
> *cloudbees-folder-plugin* 
> <https://github.com/jenkinsci/cloudbees-folder-plugin>
>
> *github-organization-folder-plugin* 
> <https://github.com/jenkinsci/github-organization-folder-plugin>
>
> <https://github.com/jenkinsci/blueocean-plugin>
>
> *blueocean-plugin* <https://github.com/jenkinsci/blueocean-plugin>
>
> <https://github.com/jenkinsci/pipeline-plugin>
>
> *pipeline-plugin* <https://github.com/jenkinsci/pipeline-plugin>
>
> *workflow-cps-plugin* <https://github.com/jenkinsci/workflow-cps-plugin>
>
> *workflow-support-plugin*
>
> *pipeline-model-definition-plugin* 
> <https://github.com/jenkinsci/pipeline-model-definition-plugin>
>
> *pipeline-stage-view-plugin* 
> <https://github.com/jenkinsci/pipeline-stage-view-plugin>
>
> *pipeline-utility-steps-plugin* 
> <https://github.com/jenkinsci/pipeline-utility-steps-plugin>
>
> *pipeline-input-step-plugin* 
> <https://github.com/jenkinsci/pipeline-input-step-plugin>
>
> *pipeline-view-plugin* <https://github.com/jenkinsci/pipeline-view-plugin>
>
> *workflow-scm-step-plugin* 
> <https://github.com/jenkinsci/workflow-scm-step-plugin>
>
>
> *github-plugin* <https://github.com/jenkinsci/github-plugin>
>
> *github-branch-source-plugin* 
> <https://github.com/jenkinsci/github-branch-source-plugin>
>
>
> *bitbucket-plugin* <https://github.com/jenkinsci/bitbucket-plugin>
>
> *bitbucket-branch-source-plugin* 
> <https://github.com/jenkinsci/bitbucket-branch-source-plugin>
>
> *bitbucket-build-status-notifier-plugin* 
> <https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin>
>
>
> *configuration-as-code-plugin* 
> <https://github.com/jenkinsci/configuration-as-code-plugin>
>
>
> *kubernetes-plugin <https://github.com/jenkinsci/kubernetes-plugin>*
>
>
> cmakebuilder  <https://plugins.jenkins.io/cmakebuilder>(request from Martin 
> as a owner)
>
>
> I'm very glad to receive a response from Martin. I'm looking forward to 
> more feedback.
>
>
> Best Regards
>
> Zhao Xiaojie
>

-- 
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/ba3409ae-0cd3-4de6-a0a8-fbe5925245fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating ruby-runtime

[Liam Newman]

I agree with Oleg.  Let's do a JEP on this to plan and implement the
deprecation, since it is a breaking change for anyone one using these
plugins.
-L.

On Wed, May 16, 2018 at 6:50 AM Daniel Beck  wrote:

>
> > On 16. May 2018, at 01:56, Owen B. Mehegan  wrote:
> >
> > From my perspective as maintainer of the "competing" GitLab plugin,
> there is one primary feature that the GitLab Hook plugin has which the
> GitLab Plugin does not. It has a single REST endpoint which all GitLab
> repos can point to. When GitLab POSTs to this, the plugin looks at the
> GitLab repo in the payload and then triggers all Jenkins jobs which clone
> that repo. I find this feature annoying, but some users prefer it, and I
> think this accounts for a lot of that plugin's users. The GitLab Plugin has
> an open PR which will allow users to create one global webhook endpoint to
> use, but they will still need to "subscribe" Jenkins jobs to that endpoint
> if they want them to be built when it receives a POST. I think the
> explicit/opinionated approach here leads to a better development process,
> but not everyone agrees.
>
> Nobody is claiming that it's not useful. In fact, gitlab-hook so far was
> the major motivator (at least for me) to keep ruby-runtime running, despite
> its problems.
>
> However, gitlab-hook plugin is unmaintained (for two years now), the
> runtime it's based on is even more unmaintained (five years), and we're
> experiencing problems inhibiting core development because of it.
>
> Realistically, the alternative here is to just not care about ruby-runtime
> related problems introduced by further core development. This would take
> care of this problem quite naturally. I'd still prefer to be explicit about
> it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNyUg8LGArr4RrKRYry71mg9sqsmAfy2U-Q80AQ058pN6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[Liam Newman]

Nicolas, 

Moving things to a separate JEP makes sense is some cases but it doesn't 
sound like the works here.  The design choices that need to be made in 
relation to credentials CasC will effect the design of the JEP-201.  Many 
plugins could be done in later JEPs, but for concepts as key as Credentials 
they would at least need to be concurrent JEPs and would need to be owned 

Putting all that aside (as that is not the original point of this thread), 
the original suggestion was to include a version field in the CasC YAML.  
You said it would not work because the version would have to take into 
account the core version and versions of all plugins, otherwise it might 
break. Does that mean the CasC YAML could break _any time_  I upgrade any 
component? Doesn't that rather defeats the purpose of CasC?  

If anything all this strengthens the argument for having at least a 
top-level version field that guarantees some level of compatibility 
(perhaps at Jenkins Core API level).  It further suggests that the CasC 
needs to include some guidance/structure for talking about CasC YAML 
changes.  "No glue code" sounds great from a code/plugin-developer 
perspective, but it is sounding more and more like a anti-feature from user 
perspective.  

For v1.0, I suppose one could argue that this is a needed design choice to 
ship in non-infinite time, but that doesn't mean it can be completely 
ignored.  Some thought will still need to be given to how to ease this pain 
or at least measure and clearly communicate how often breaks would have 
occurred in the last year if CasC had been around.

-L. 








On Monday, May 14, 2018 at 8:22:53 AM UTC-7, Jesse Glick wrote:
>
> On Fri, May 11, 2018 at 5:44 PM, nicolas de loof 
>  wrote: 
> > Secret is already supported based on jenkins-core registered stapler 
> > converters. 
>
> Yes; my point was only that due to the nature of secrets, JCasC needs 
> to support keeping the actual values separate from the main YAML file 
> somehow—whether via a generic variable interpolation system, or 
> symmetric encryption, etc. This is already part of the reference 
> implementation, which is good. 
>
> >> JEP-201 is a new 
> >> feature, so its developers are responsible for designing and 
> >> implementing appropriate integrations with existing foundational 
> >> components of Jenkins. 
> > 
> > I strongly disagree with this. From my perspective JEP-201 is about 
> generic 
> > mechanism to support configuration-as-code without glue code and option 
> for 
> > custom adapters where required. 
>
> Yes, that is fine. 
>
> > Maybe this should be discussed in a subsequent JEP if you consider this 
> > _that_ important. 
>
> Perhaps, but my perspective is that a JEP should be reasonably 
> self-contained and define enough detail to implement an MVP, which 
> would certainly include support for credentials. If you defer this 
> aspect to an unspecified future JEP then there is a risk that this 
> planning either gets dropped, or that the integration turns out to 
> require fundamental design changes which are difficult to retrofit. In 
> other words, a JEP should describe a complete user story. 
>
> Obviously there are plenty of plugins which should just have routine 
> integration with JCasC—fully automatic or with minor changes. But we 
> can reasonably expect that the endpoint configuration for the Aqua 
> Security Scanner plugin (whatever that is) could be managed without 
> “interesting” issues arising, and anyway most users of JCasC would not 
> be using this plugin. 
>
> The Pipeline comparison is a little tough, since the core design there 
> long preceded the JEP process and was not formalized well, but the 
> analogy works so far as we are discussing modularity of code. For 
> example, the `withCredentials` step is indeed implemented in a 
> distinct credentials-related plugin, but there were some subtle 
> aspects that mandated special treatment elsewhere: the environment 
> variables in a block in `program.dat` needed to be kept encrypted, 
> which required API changes; and Blue Ocean needs to know to hide 
> secrets from step summaries, which also required special consideration 
> in other components. 
>

-- 
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/f10a6015-ddd6-476d-bddb-c9c4e7658329%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[Liam Newman]

Just FYI: Nicolas asked a question of me in a GH comment:
https://github.com/jenkinsci/jep/commit/78bede6c731e7a85a90ca374ca1c394e219aa961#commitcomment-28894501

@bitwiseman  Discussion on plugin management 
> was probably introduced in this JEP too early as we don't have a prototype 
> for it (update center doesn't even have the required metadata)
> Would it make sense to revert this commit so we can follow-up with JCasC 
> as an approved JEP, and prepare another JEP about plugin management (which 
> would apply to docker images and probably few other use-cases) ?


I figured I'd respond here rather than buried in GH comments. 

Nicolas, 
To be clear:  I'm not Reviewer for this JEP.   I set it back to this 
"Draft" with the agreement of the sponsor as part of a clarification of the 
JEP process.  

It sounds like Ewelina is working on further updates (including 
incorporating the JOM feedback - yay!) and hasn't requested Review for 
Acceptance yet.  As sponsor, when she believes the JEP meets the 
requirements for Accepted status, I'm sure she'll request that it be 
reviewed again. 

Ewelina, 
Thanks for taking the time to incorporate feedback and to make sure 
everyone is clear about the on-going status of the project.  I don't know 
that I need to be involved in the maintainers meeting, but feel free to 
send me an invite. 

-Liam



On Tuesday, May 8, 2018 at 3:34:28 AM UTC-7, Ewelina Wilkosz wrote:
>
> just a short update - JEP update in progress, next week we're planning a 
> short maintainers status meeting where I hope to clarify stuff and PR will 
> be sent
>
> On Thursday, May 3, 2018 at 12:24:07 AM UTC+2, Jesse Glick wrote:
>>
>> On Wed, May 2, 2018 at 3:58 PM, Ewelina Wilkosz  
>> wrote: 
>> > Any of you interested in contributing to that one? Please let me know, 
>> so we 
>> > don't duplicate 
>>
>> I will leave the reasoning to you! Just bringing up things that seemed 
>> to merit discussion. 
>>
>

-- 
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/56c5a171-f7ed-4f53-bd67-c79bb182bb91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins X | JEP-400] Weekly on air hangout/office hours

[Liam Newman]

This has been added to the Jenkins Calendar: 

https://jenkins.io/event-calendar/ 
<https://www.google.com/url?q=https%3A%2F%2Fjenkins.io%2Fevent-calendar%2F=D=1=AFQjCNFajljqkZI28GxMuEoBTFZabEofHg>


The event is here:
https://calendar.google.com/event?action=TEMPLATE=NWxyaWM1cnUwaTVhYnE1Njc1NnJoaDZqNnJfMjAxODA1MTdUMTYwMDAwWiA0c3MxMmYwbXFyM3RicDF0MmZlMzY5c2xmNEBn=4ss12f0mqr3tbp1t2fe369slf4%40group.calendar.google.com=ALL

I've set it up as a https://jenkins.io/hangout to start which means anyone 
can join and participate, but the sessions will not be recorded. Does that 
sound good to everyone? 



On Thursday, May 3, 2018 at 11:44:34 AM UTC-7, Liam Newman wrote:
>
> Okay, I'll set it up for the 17th.  
>
> On Wednesday, May 2, 2018 at 12:40:32 AM UTC-7, James Rawlings wrote:
>>
>>
>> On 2 May 2018, at 05:21, Michael Neale <mne...@cloudbees.com> wrote:
>>
>> Lets see what James says about May 8th (should be ok). 
>>
>> Yeah can we go for every other Thursday starting the 17th May?  There’s 
>> conferences and meetings on next week so starting the following would be 
>> best.
>>
>>
>> On those other topics - yes bigger discussion. jenkins-x/jx issues are 
>> currently used as github issues are "dogfooded" - but I believe there is 
>> JIRA support so I think in time they can move to jira under a jenkins-x 
>> component. 
>>
>> As for repos: there are currently 36 (and growing) in the org - so would 
>> need to namespace them to move them into main org. A lot of them are 
>> infra/biuld pack type things. There is also jenkins-infra which has 64, 
>> which is separate (but I guess it is managed out of band). If it is a 
>> matter of managing access to repos etc - could be solved I am sure. 
>>
>> On Wednesday, May 2, 2018 at 1:26:58 PM UTC+10, Liam Newman wrote:
>>>
>>> Oleg: By "listing Jenkins X under sub-projects" do you also mean moving 
>>> the repositories under jenkinsci org on github and using the Jenkins JIRA?  
>>> I support that, but it something that should probably go on a separate 
>>> thread.  
>>>
>>> James, Michael,
>>> Obviously I dropped the ball on April 26th.  Shall I schedule the next 
>>> meeting on the May 8th?
>>>
>>> On Thursday, April 19, 2018 at 3:30:12 AM UTC-7, Oleg Nenashev wrote:
>>>>
>>>> No, it can happen at any moment IMHO. I do not see JEP-400 to be a 
>>>> blocker for referencing this project from jenkins.io. OTOH I am not 
>>>> sure it is within Jenkins organization governance now. E.g. using external 
>>>> org blocks Jenkins GitHub admins from managing permission requests, etc. 
>>>> Are there plans to migrate by the way? JEP-400 does not cover these 
>>>> governance things.
>>>>
>>>> BR, Oleg
>>>>
>>>> On Thu, Apr 19, 2018 at 12:17 PM, Michael Neale <mne...@cloudbees.com> 
>>>> wrote:
>>>>
>>>>> Does that have to happen after the JEP is accepted? 
>>>>>
>>>>> -- 
>>>>> 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/j_pqY84Pjag/unsubscribe
>>>>> .
>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>> jenkinsci-de...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/ed611774-7746-48d6-bfa9-1b1ac3592b00%40googlegroups.com
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>> -- 
>> 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-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/747821e2-6de5-4b9a-bc5f-c08632ae54a6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/747821e2-6de5-4b9a-bc5f-c08632ae54a6%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
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/46c5e706-2f32-4343-bd8d-042e16b4f5ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins X | JEP-400] Weekly on air hangout/office hours

[Liam Newman]

Okay, I'll set it up for the 17th.  

On Wednesday, May 2, 2018 at 12:40:32 AM UTC-7, James Rawlings wrote:
>
>
> On 2 May 2018, at 05:21, Michael Neale <mne...@cloudbees.com > 
> wrote:
>
> Lets see what James says about May 8th (should be ok). 
>
> Yeah can we go for every other Thursday starting the 17th May?  There’s 
> conferences and meetings on next week so starting the following would be 
> best.
>
>
> On those other topics - yes bigger discussion. jenkins-x/jx issues are 
> currently used as github issues are "dogfooded" - but I believe there is 
> JIRA support so I think in time they can move to jira under a jenkins-x 
> component. 
>
> As for repos: there are currently 36 (and growing) in the org - so would 
> need to namespace them to move them into main org. A lot of them are 
> infra/biuld pack type things. There is also jenkins-infra which has 64, 
> which is separate (but I guess it is managed out of band). If it is a 
> matter of managing access to repos etc - could be solved I am sure. 
>
> On Wednesday, May 2, 2018 at 1:26:58 PM UTC+10, Liam Newman wrote:
>>
>> Oleg: By "listing Jenkins X under sub-projects" do you also mean moving 
>> the repositories under jenkinsci org on github and using the Jenkins JIRA?  
>> I support that, but it something that should probably go on a separate 
>> thread.  
>>
>> James, Michael,
>> Obviously I dropped the ball on April 26th.  Shall I schedule the next 
>> meeting on the May 8th?
>>
>> On Thursday, April 19, 2018 at 3:30:12 AM UTC-7, Oleg Nenashev wrote:
>>>
>>> No, it can happen at any moment IMHO. I do not see JEP-400 to be a 
>>> blocker for referencing this project from jenkins.io. OTOH I am not 
>>> sure it is within Jenkins organization governance now. E.g. using external 
>>> org blocks Jenkins GitHub admins from managing permission requests, etc. 
>>> Are there plans to migrate by the way? JEP-400 does not cover these 
>>> governance things.
>>>
>>> BR, Oleg
>>>
>>> On Thu, Apr 19, 2018 at 12:17 PM, Michael Neale <mne...@cloudbees.com> 
>>> wrote:
>>>
>>>> Does that have to happen after the JEP is accepted? 
>>>>
>>>> -- 
>>>> 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/j_pqY84Pjag/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to 
>>>> jenkinsci-de...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/ed611774-7746-48d6-bfa9-1b1ac3592b00%40googlegroups.com
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
> -- 
> 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-de...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/747821e2-6de5-4b9a-bc5f-c08632ae54a6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/747821e2-6de5-4b9a-bc5f-c08632ae54a6%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/8b763cd3-112a-4ec7-8e6c-cc580200175d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins X | JEP-400] Weekly on air hangout/office hours

[Liam Newman]

Oleg: By "listing Jenkins X under sub-projects" do you also mean moving the 
repositories under jenkinsci org on github and using the Jenkins JIRA?  I 
support that, but it something that should probably go on a separate 
thread.  

James, Michael,
Obviously I dropped the ball on April 26th.  Shall I schedule the next 
meeting on the May 8th?

On Thursday, April 19, 2018 at 3:30:12 AM UTC-7, Oleg Nenashev wrote:
>
> No, it can happen at any moment IMHO. I do not see JEP-400 to be a blocker 
> for referencing this project from jenkins.io. OTOH I am not sure it is 
> within Jenkins organization governance now. E.g. using external org blocks 
> Jenkins GitHub admins from managing permission requests, etc. Are there 
> plans to migrate by the way? JEP-400 does not cover these governance things.
>
> BR, Oleg
>
> On Thu, Apr 19, 2018 at 12:17 PM, Michael Neale  > wrote:
>
>> Does that have to happen after the JEP is accepted? 
>>
>> -- 
>> 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/j_pqY84Pjag/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/ed611774-7746-48d6-bfa9-1b1ac3592b00%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/aa1a7de2-fe02-4a2d-9007-1cad695ea8b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Using JEP process for future design changes to Declarative Pipeline?

[Liam Newman]

Andrew Bayer has been doing great work on Declarative pipeline.  He's done 
excellent work creating clear and understandable design discussions in JIRA 
and in the Pull Requests to the plugin. From design to implementation 
(including keeping documention) up to date, I think his work has been top 
notch. 


That said, JIRA and PRs are not the idea place to have design discussions 
nor the best place to document the reasoning behind those design choice.  
Details get lost in long threads, it is not always clear what stage the 
design is at, and the actual final proposed design is sometimes less clear 
that it could be.  

Now that we have the Jenkins Enhancement Proposal 
<https://github.com/jenkinsci/jep/tree/master/jep/1> process, I think it 
would be great if we started using it to track future design changes to 
Declarative Pipeline DSL.  

I'd like to know what folks (including Andrew) think of this idea? 

Thanks,
Liam Newman
Jenkins Evangelist

-- 
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/d48c4626-d7cc-4fa3-b281-caccd6e0f0cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins X status

[Liam Newman]

If you're generating HTML, it seems like you'd be able to generate asciidoc 
pretty easily.That would be great. 

On Tuesday, May 1, 2018 at 12:20:29 AM UTC-7, Michael Neale wrote:
>
> Is there a way to x-post that to a jenkins.io blog? (even as a 
> PR/somewhat automatically?)
>
> On Saturday, April 28, 2018 at 1:55:36 AM UTC+10, Rob Davies wrote:
>>
>> We've been pretty busy - but always need more help from the Jenkins 
>> community. Here's the latest changes in Jenkins X land: 
>> http://jenkins-x.io/news/changes-april-27-2018/
>>
>> thanks,
>>
>> Rob
>>
>>
>> On Friday, April 13, 2018 at 7:53:09 AM UTC+1, Rob Davies wrote:
>>>
>>> Whilst the Jenkins X JEP proposal is still under consideration 
>>>  -  
>>> I thought it would be worthwhile giving a quick summary of where we stand 
>>> with the project.
>>> There's actually a great summary of community stats done in a generated 
>>>  blog using jenkins-X 
>>> but the hlighlights include  integration with Github issues, GitHub 
>>> Enterprise and Jira. Continued development of BitBucket and 
>>> Gitea integrations. We have gained 10 new commiiters and 18 new 
>>> contributors - which is fantastic - but we would love more! Work is being 
>>> undertaken on integrating Anhttps://github.com/anchorechore for 
>>> validation of container images in pipelines. Anchore also have a Jenkins 
>>> plugin.
>>>
>>> Rob
>>>
>>

-- 
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/8cd7f891-5b2a-41b4-84e4-905b6c24a8cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[Liam Newman]

(offlist)
I want to be clear: I was not singling you out or criticizing. This looks
like a challenging thread, and you're doing a great job staying positive
and open to ideas.

If there's anything I can do to help just say so.

Thanks for all your hard work,
Liam Newman

On Sun, Apr 22, 2018 at 11:24 PM Ewelina Wilkosz <ewelin...@gmail.com>
wrote:

> Thanks for keeping your eye on it Liam, I will take necessary actions this
> week!
>
>
> On Friday, April 20, 2018 at 8:26:45 PM UTC+2, Liam Newman wrote:
>>
>> Ewelina, Nicolas,
>>
>> I'm jumping in because I don't see anyone mentioning who will be doing
>> this.
>>
>> As JEP-1 sponsor, I would like to remind you that part of your duties as
>> sponsors of JEP-201 include different viewpoints and design suggestions in
>> your JEP. (I'm jumping in because I don't see anyone mentioning who will be
>> doing this.)  Even if you choose not to use the suggestions, they need to
>> be represented in the "Reasoning" section.
>>
>> Just as Jesse pulled this feedback to a discussion here so it wouldn't be
>> lost in IRC, it will need to be distilled from this extended discussion to
>> be added to the JEP.  Here's two examples of "Reasoning" sections with
>> significant content:
>>
>> https://github.com/jenkinsci/jep/tree/master/jep/1#reasoning
>> https://github.com/jenkinsci/jep/tree/master/jep/200#reasoning
>>
>> It looks to me like there are at least three threads here: automatic
>> symbol inference, YAML Map syntax and Credentials, and Replacing  Job DSL
>> Groovy syntax. There might also be a general list of features that have
>> been deemed out-of-scope for the current release.
>>
>> You may ask Jesse if he'd be willing to submit PRs (adding to
>> "Specification" or "Reasoning"), but ultimately it is your responsibility
>> to make sure it happens.
>>
>> Thanks,
>> -L.
>>
>>
>>
>> On Tuesday, April 17, 2018 at 11:31:30 PM UTC-7, Ewelina Wilkosz wrote:
>>>
>>> interesting discussion!
>>>
>>> I agree we can have a nicer way of configuring job, to keep the
>>> consistency, but I also agree with Nicolas about not wanting to "re-invent
>>> the wheel" - many users have their job dsls ready, so the transition may be
>>> easier if they don't need to learn a new syntax, that was my motivation for
>>> keeping job dsl. Alternative solution may exist next to job dsl support I
>>> believe
>>>
>>> On Wednesday, April 18, 2018 at 6:53:58 AM UTC+2, nicolas de loof wrote:
>>>>
>>>>
>>>>
>>>> 2018-04-18 0:42 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:
>>>>
>>>>> On Tue, Apr 17, 2018 at 4:45 PM, nicolas de loof
>>>>> <nicolas...@gmail.com> wrote:
>>>>> > Job class hierarchy is full of hand written JSON parsing
>>>>>
>>>>> I suspect such cases are fixable, which would take some work, but on
>>>>> the other hand we would get a clearer code base as a result anyway.
>>>>>
>>>>
>>>> Sure, but this will be for future version then
>>>> We want JCasC to support current releases of Jenkins by Praqma
>>>> customers (and others), not require bleeding edge Jenkins core.
>>>>
>>>>
>>>>>
>>>>> --
>>>>> 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-de...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03rVj6r1tWfwYeO1QKeDMtDYjuc8fF0Se%2B4Rh9qbZFvg%40mail.gmail.com
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
> 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/a60f5c91-d462-4cf0-9e29-9e7319ccc250%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a60f5c91-d462-4cf0-9e29-9e7319ccc250%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNzLQsaeGQT1PAGJvBNBWY8Y%2BM8EBGXiUxr9bv4%3Dia_Kvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: External Artifact Storage

[Liam Newman]

Re: Accepted status: 
I have a PR 76  pending merge 
that (among other things) clarifies the meaning of "Accepted" status.  

One of the key points is that review and acceptance should not be taken 
lightly.

By marking a JEP as "Accepted" the Reviewer indicates they believe that the 
JEP has 

clear scope, design completeness, community consensus, and (if applicable) 

in-progress implementation.  Without all of these a JEP cannot be accepted. 

For this reason, it is not unusual for JEPs to remain in "Draft" state even 
after 

they have strong community support and progressing implementation. They 

must still pass the other criteria, such as scoping and design 
completeness."


I hope this PR answers people's questions.  If it doesn't, I'd like to hear 
from them how to improve it.

Thanks,
-L.

 



On Friday, April 20, 2018 at 1:51:58 PM UTC-7, Kohsuke Kawaguchi wrote:
>
> This is a great effort that tackles a part of a broad problem space for 
> large scale / cloud native Jenkins users. My hats off to Carlos, Jesse, and 
> Oleg for driving these efforts. I've assigned Jesse as BDFL Delegate to 
> this JEP.
>
> For the future, a few nit pickings. I feel that the write-up of this JEP 
> mixes the core part and S3 specific part in one piece, which muddies water 
> a bit. For example, it reads "Core APIs already existed ..., but lacked the 
> crucial capability ... to provide a satisfactory S3 implementation," which 
> makes it sound like this change was needed to make S3 work, but really 
> AFAIK the core changes are aiming at all cloud blob stores, not just S3. I 
> also know Carlos and Jesse are focused on doing S3 as companion 
> implementation of this core change, but I also believe we welcome (and in 
> fact encourage) other people to do other cloud implementations, like Azure, 
> and there's nothing in the core changes that tie us to S3.
>
> I also think the amount of coding effort that went into this is well past 
> the criteria that I expect for "Accepted", if that's what led to Tyler's 
> commentary below, but I'm probably missing some context.
>
> So overall, for future JEPs in this space, it'd be good to get a JEP up a 
> little sooner so that we can overlap the time it takes for the actual 
> development and the consensus building.
>
> On Fri, Apr 20, 2018 at 9:37 AM R. Tyler Croy  > wrote:
>
>> (replies inline)
>>
>> On Fri, 13 Apr 2018, Carlos Sanchez wrote:
>>
>> > PR submitted at https://github.com/jenkinsci/jep/pull/83
>>
>>
>> Related to this work is this pull request which implements extensions to
>> VirtualFile, which I would consider very key to this work:
>> https://github.com/jenkinsci/jenkins/pull/3302
>>
>> With that pull request there have been some questions raised about how 
>> the JEP
>> Workflow interacts with the implementation workflow, and merging of code 
>> into
>> plugin and core repositories. I wanted to share the expectations I had in 
>> mind
>> when bringing over parts of PEP into JEP-1.
>>
>> The workflow for a Standards JEP is generally going to be 
>> Draft->Accepted[0]->Final[1]
>>
>> JEP-1 is somewhat intentionally vague on how these map to merges of pull
>> requests and APIs. My original thoughts around this were that this would 
>> be a
>> good thing and allow us the most flexibility in writing code alongside
>> discussing design and APIs, depending on the repository and design. I 
>> recognize
>> how this ambiguity also leaves room for confusion.
>>
>>
>> Working backwards, Final is the most clear and obvious in my opinion. A 
>> JEP
>> marked as Final means designs and APIs are merged, finalized, and 
>> considered
>> "supported" for whatever our hand-wavey-API-support-policy is (i.e. public
>> APIs) in whatever project they're being merged.
>>
>> The requirements for implementation around Accepted[0] much more loosely
>> defined as:
>>
>> "The proposed implementation, if applicable, must be solid, must not 
>> complicate
>> Jenkins unduly, and must be the same license as the component the 
>> proposal is
>> meant to added to"
>>
>> In the case of Jenkins Essentials, we're merging code regardless of 
>> Accepted,
>> or even Draft JEP status, because obviously, that's most expedient given 
>> the
>> state of that project.
>>
>> In the case of Jenkins plugins and core which are already being used, I
>> understand that is not the case. However, I think it would be a failure 
>> for JEP
>> if we are reluctant to merge code and make _use_ of it before the 
>> "Accepted" or
>> "Final" states are reached.
>>
>> To a certain extent I believe that no API or design can be safely 
>> considered
>> Final without real world experimental or beta usage.  Hiding something 
>> behind a
>> feature flag, or a @Beta annotation, for core or plugins is (IMHO) a 
>> really
>> good thing to strive for even in the Draft stage to get _real_ usage of 
>> designs
>> in the hands of testers and users. 

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[Liam Newman]

Ewelina, Nicolas,

I'm jumping in because I don't see anyone mentioning who will be doing this.

As JEP-1 sponsor, I would like to remind you that part of your duties as 
sponsors of JEP-201 include different viewpoints and design suggestions in 
your JEP. (I'm jumping in because I don't see anyone mentioning who will be 
doing this.)  Even if you choose not to use the suggestions, they need to 
be represented in the "Reasoning" section.

Just as Jesse pulled this feedback to a discussion here so it wouldn't be 
lost in IRC, it will need to be distilled from this extended discussion to 
be added to the JEP.  Here's two examples of "Reasoning" sections with 
significant content:

https://github.com/jenkinsci/jep/tree/master/jep/1#reasoning
https://github.com/jenkinsci/jep/tree/master/jep/200#reasoning

It looks to me like there are at least three threads here: automatic symbol 
inference, YAML Map syntax and Credentials, and Replacing  Job DSL Groovy 
syntax. There might also be a general list of features that have been 
deemed out-of-scope for the current release. 

You may ask Jesse if he'd be willing to submit PRs (adding to 
"Specification" or "Reasoning"), but ultimately it is your responsibility 
to make sure it happens. 

Thanks, 
-L. 



On Tuesday, April 17, 2018 at 11:31:30 PM UTC-7, Ewelina Wilkosz wrote:
>
> interesting discussion!
>
> I agree we can have a nicer way of configuring job, to keep the 
> consistency, but I also agree with Nicolas about not wanting to "re-invent 
> the wheel" - many users have their job dsls ready, so the transition may be 
> easier if they don't need to learn a new syntax, that was my motivation for 
> keeping job dsl. Alternative solution may exist next to job dsl support I 
> believe
>
> On Wednesday, April 18, 2018 at 6:53:58 AM UTC+2, nicolas de loof wrote:
>>
>>
>>
>> 2018-04-18 0:42 GMT+02:00 Jesse Glick :
>>
>>> On Tue, Apr 17, 2018 at 4:45 PM, nicolas de loof
>>>  wrote:
>>> > Job class hierarchy is full of hand written JSON parsing
>>>
>>> I suspect such cases are fixable, which would take some work, but on
>>> the other hand we would get a clearer code base as a result anyway.
>>>
>>
>> Sure, but this will be for future version then
>> We want JCasC to support current releases of Jenkins by Praqma customers 
>> (and others), not require bleeding edge Jenkins core.
>>  
>>
>>>
>>> -- 
>>> 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-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03rVj6r1tWfwYeO1QKeDMtDYjuc8fF0Se%2B4Rh9qbZFvg%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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/80dad51b-9adb-4f23-8e2a-d6f41dabf45a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins X | JEP-400] Weekly on air hangout/office hours

[Liam Newman]

That is totally doable.  What day of the week what time (including 
timezone)? 

On Tuesday, April 17, 2018 at 4:49:12 PM UTC-7, Michael Neale wrote:
>
> Hey all - James Rawlings has proposed a weekly on air/office hours. I know 
> there is a jenkinscicd youtube channel capable of doing scheduled hangouts 
> on air, so I think that would be the best place to do it? Liam? 
>

-- 
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/10aff743-3da3-4ae0-8855-30fcc28c5076%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Instance Health Checking JEP: ready for first review

[Liam Newman]

Jesse,
Thanks for the reminder about that point around commenting.

As an editor, I have no objections to having pre-draft discussions in
whatever way contributors see fit.

As a sponsor of JEP-1, it is important to me that when a sponsor submits a
JEP for "Approval as Draft", that feedback they get on _that_ PR focuses on
issues that would prevent the JEP being approved as draft rather than on
design or other questions.  I'll add a note about this to
https://github.com/jenkinsci/jep/pull/76 .

-Liam




On Tue, Apr 10, 2018 at 12:41 PM Baptiste Mathus  wrote:

> 2018-04-10 16:33 GMT+02:00 R. Tyler Croy :
>
>> (replies inline)
>>
>> On Tue, 10 Apr 2018, Jesse Glick wrote:
>>
>> > I for one would find it easier to comment on a PR, but IIRC JEP
>> > editors have discouraged this for some reason
>> >
>> >
>> > ???Healthness??? is not a word???it is just ???health???.
>> >
>> >
>> > I would suggest `/metrics/evergreen/healthcheck` just return an empty
>> > JSON document, or a simple ???OK??? marker by default???only listing
>> things
>> > that are _not_ healthy.
>>
>> It was my understanding that this format was simply the Dropwizard
>> healthcheck
>> format.
>>
>
> Yes. Exactly. Also, though TBH I didn't test it myself yet, I expect one
> can contribute healthchecks, and they'd appear there.
>
> That "OK" idea is already somehow available if one enables the `canPing`
> configuration field. Then `curl`ing the URL will reply with just PONG and
> http-200 IIRC. But I felt this was unnecessary to enable that too.
>
>
>>
>> Do you have some reasoning for this you could share? Otherwise this seems
>> like
>> a bit of personal preference to me, but I'm sure there's some logic I
>> could be
>> missing here.
>>
>>
>>
>>
>> --
>> 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/20180410143346.discdbodxgiudmfz%40grape.lasagna.io
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CANWgJS6FcSp_faJL5C26-xESdUrSQvw%3D40%2BGVxf-SkWM5TOvQQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNxaUqBC6ckV-BE9qn%3DabQpoZqKMTE3oQ%3Di%3DGpqHkWG6Tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: JEP: Modification of "Accepted" JEPs

[Liam Newman]

Hello all,
I've attempted to synthesize the key points made here into a PR for JEP 1:
https://github.com/jenkinsci/jep/pull/76

The scope of this change expanded a bit, but I think the result is clearer.
Please feel free to comment (or even better to commit edits directly). 

Thanks, 
Liam


On Monday, March 26, 2018 at 1:25:34 PM UTC-7, Liam Newman wrote:
>
> Andrew,
>
> That's an interesting point as well. The process is still relatively new, 
> so it's not surprising that there's a learning curve and a need for more 
> examples. JEPs with tighter focus will definitely move through the process 
> more quickly, since they will require less discussion, design-time, 
> implementation time, and consensus building.   JEP-200 was a good example 
> of that tight focus and it still took some time.
>
> One way that Tyler has been addressing the scope considerations in 
> relation the Jenkins Essentials is splitting the overall project into 
> multiple JEPs.  JEP-300 covers the overall goals and high-level design, and 
> delegates the internal design of those components to sub-JEPs that are 
> being filed as work gets rolling.   I don't know if that means JEP-300 will 
> be accepted sooner or will remain as draft, but it looks like that will be 
> the case.  
>
> It would be nice to have more JEPs filed to for a base of examples we can 
> point people to, but I suspect we'll have to wait for that to grow 
> organically over time.
>
> -L. 
>
>
> On Sat, Mar 24, 2018 at 7:48 AM Andrew Bayer <andrew.ba...@gmail.com> 
> wrote:
>
>> I think it’s more a cultural thing re comfortableness of followup JEPs - 
>> we need to have precedents and examples so that people will feel like oh, 
>> it’s ok that this stuff didn’t get into that JEP, we can just do a new JEP 
>> with it. Leaving proposals open for too long in order to make sure every 
>> possible tangentially related matter gets in is a path to stagnation. We’re 
>> far better off with more JEPs of potentially smaller size/scope, 
>> potentially amending earlier JEPs, than a small number of bloated ones, IMO.
>>
>> A.
>>
>> On Sat, Mar 24, 2018 at 9:34 AM Liam Newman <bitwise...@gmail.com> wrote:
>>
>>> This is a ton of great feedback, thanks!  
>>>
>>> Ewelina,
>>>
>>> JEPs have a number of purposes, but they are definitely _not_ meant to 
>>> stifle innovation.  At minimum though, they are meant to provide a medium 
>>> for building consensus on the design and implementation of major 
>>> features/processes of the Jenkins (and related) project.  
>>>
>>> Without JEP, contributors such as yourself, might do months of work only 
>>> to have that work rejected or asked to be redesigned.  From the other side, 
>>> the Project might get random contributors who ride in and want to have drop 
>>> in some massive features without having discussed and reviewed with the 
>>> rest of the project. 
>>>
>>> I think the main misunderstanding (due to lack of clarity in JEP-1) is 
>>> the idea that a JEP must be "Accepted" in order for contributors to have 
>>> confidence in the value and validity of their work. That is absolutely not 
>>> the case.
>>>
>>> "Accepted" means that that Reviewer and Sponsor have looked at the JEP 
>>> and agreed that _scoping and design_ are complete and have the consensus of 
>>> the community, and that what remains is completing the (already well 
>>> underway) implementation.  "Accepted" is a description of the technical 
>>> state of the proposed component/feature/process.  "Accepted" is _not_ (and 
>>> should not be viewed or used as) a "vote of confidence".  
>>>
>>> Conversely, "Draft" is not a commentary on the likelihood that the JEP 
>>> will eventually be "Accepted".  That can only determined by the Sponsors 
>>> and the Reviewers based on discussion and feedback on the mailing list or 
>>> other forums. "Draft" is _not_ (and should not be viewed as) an indicator 
>>> of any lack of confidence in a proposal. 
>>>
>>> > Now when I see a requirement 
>>> *> "all 'significant changes' to a JEP should be completed before it is 
>>> Accepted"*
>>> > it makes me worry that if I end up working on next JEP, for another 
>>> project, 
>>> > I will be very careful and it will take ages to put it into "Accepted" 
>>> (maybe it's
>>> > not a problem). And then, like with JCasC, we learn while we im

Re: L10n of JS files

[Liam Newman]

Ullrich,

Could you give a little more context as to what you're asking about?

Liam Newman


On Wed, Mar 28, 2018 at 1:05 AM Ullrich Hafner <ullrich.haf...@gmail.com>
wrote:

> Is it possible to localize JS files? Or do I need to place localized
> labels for some JS charts on invisible DOM elements using jelly files and
> then read the content in the JS script?
>
> --
> 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/5E723154-EDA7-4AE9-850E-C93BB2656993%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNzjhFoXintJQzfVRfBQfGdLwpCYCq9wTj%2BF8NxFR11cfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: JEP: Modification of "Accepted" JEPs

[Liam Newman]

Andrew,

That's an interesting point as well. The process is still relatively new,
so it's not surprising that there's a learning curve and a need for more
examples. JEPs with tighter focus will definitely move through the process
more quickly, since they will require less discussion, design-time,
implementation time, and consensus building.   JEP-200 was a good example
of that tight focus and it still took some time.

One way that Tyler has been addressing the scope considerations in relation
the Jenkins Essentials is splitting the overall project into multiple
JEPs.  JEP-300 covers the overall goals and high-level design, and
delegates the internal design of those components to sub-JEPs that are
being filed as work gets rolling.   I don't know if that means JEP-300 will
be accepted sooner or will remain as draft, but it looks like that will be
the case.

It would be nice to have more JEPs filed to for a base of examples we can
point people to, but I suspect we'll have to wait for that to grow
organically over time.

-L.


On Sat, Mar 24, 2018 at 7:48 AM Andrew Bayer <andrew.ba...@gmail.com> wrote:

> I think it’s more a cultural thing re comfortableness of followup JEPs -
> we need to have precedents and examples so that people will feel like oh,
> it’s ok that this stuff didn’t get into that JEP, we can just do a new JEP
> with it. Leaving proposals open for too long in order to make sure every
> possible tangentially related matter gets in is a path to stagnation. We’re
> far better off with more JEPs of potentially smaller size/scope,
> potentially amending earlier JEPs, than a small number of bloated ones, IMO.
>
> A.
>
> On Sat, Mar 24, 2018 at 9:34 AM Liam Newman <bitwise...@gmail.com> wrote:
>
>> This is a ton of great feedback, thanks!
>>
>> Ewelina,
>>
>> JEPs have a number of purposes, but they are definitely _not_ meant to
>> stifle innovation.  At minimum though, they are meant to provide a medium
>> for building consensus on the design and implementation of major
>> features/processes of the Jenkins (and related) project.
>>
>> Without JEP, contributors such as yourself, might do months of work only
>> to have that work rejected or asked to be redesigned.  From the other side,
>> the Project might get random contributors who ride in and want to have drop
>> in some massive features without having discussed and reviewed with the
>> rest of the project.
>>
>> I think the main misunderstanding (due to lack of clarity in JEP-1) is
>> the idea that a JEP must be "Accepted" in order for contributors to have
>> confidence in the value and validity of their work. That is absolutely not
>> the case.
>>
>> "Accepted" means that that Reviewer and Sponsor have looked at the JEP
>> and agreed that _scoping and design_ are complete and have the consensus of
>> the community, and that what remains is completing the (already well
>> underway) implementation.  "Accepted" is a description of the technical
>> state of the proposed component/feature/process.  "Accepted" is _not_ (and
>> should not be viewed or used as) a "vote of confidence".
>>
>> Conversely, "Draft" is not a commentary on the likelihood that the JEP
>> will eventually be "Accepted".  That can only determined by the Sponsors
>> and the Reviewers based on discussion and feedback on the mailing list or
>> other forums. "Draft" is _not_ (and should not be viewed as) an indicator
>> of any lack of confidence in a proposal.
>>
>> > Now when I see a requirement
>> *> "all 'significant changes' to a JEP should be completed before it is
>> Accepted"*
>> > it makes me worry that if I end up working on next JEP, for another
>> project,
>> > I will be very careful and it will take ages to put it into "Accepted"
>> (maybe it's
>> > not a problem). And then, like with JCasC, we learn while we implement
>> it,
>> > we discover issues and things that we can't do the way we want to do.
>> > Do we have to discover all of that before "Accepting" JEP?
>>
>> In short, yes, but as you might gather from my response above, that is
>> not a bad thing.
>>
>> In the case of JEP-201, there has been no commentary it indicate that it
>> lacks support, nor any doubt about the value of the work being done.  I
>> think that the lack of clarity about the meaning of "Accepted" extends to
>> the reviewers, so JEP-201 was marked as "Accepted" before the design was
>> sufficiently complete.   But I also personally have no doubt that once the
>> design is co

Re: JEP: Modification of "Accepted" JEPs

[Liam Newman]

This is a ton of great feedback, thanks!

Ewelina,

JEPs have a number of purposes, but they are definitely _not_ meant to
stifle innovation.  At minimum though, they are meant to provide a medium
for building consensus on the design and implementation of major
features/processes of the Jenkins (and related) project.

Without JEP, contributors such as yourself, might do months of work only to
have that work rejected or asked to be redesigned.  From the other side,
the Project might get random contributors who ride in and want to have drop
in some massive features without having discussed and reviewed with the
rest of the project.

I think the main misunderstanding (due to lack of clarity in JEP-1) is the
idea that a JEP must be "Accepted" in order for contributors to have
confidence in the value and validity of their work. That is absolutely not
the case.

"Accepted" means that that Reviewer and Sponsor have looked at the JEP and
agreed that _scoping and design_ are complete and have the consensus of the
community, and that what remains is completing the (already well underway)
implementation.  "Accepted" is a description of the technical state of the
proposed component/feature/process.  "Accepted" is _not_ (and should not be
viewed or used as) a "vote of confidence".

Conversely, "Draft" is not a commentary on the likelihood that the JEP will
eventually be "Accepted".  That can only determined by the Sponsors and the
Reviewers based on discussion and feedback on the mailing list or other
forums. "Draft" is _not_ (and should not be viewed as) an indicator of any
lack of confidence in a proposal.

> Now when I see a requirement
*> "all 'significant changes' to a JEP should be completed before it is
Accepted"*
> it makes me worry that if I end up working on next JEP, for another
project,
> I will be very careful and it will take ages to put it into "Accepted"
(maybe it's
> not a problem). And then, like with JCasC, we learn while we implement
it,
> we discover issues and things that we can't do the way we want to do.
> Do we have to discover all of that before "Accepting" JEP?

In short, yes, but as you might gather from my response above, that is not
a bad thing.

In the case of JEP-201, there has been no commentary it indicate that it
lacks support, nor any doubt about the value of the work being done.  I
think that the lack of clarity about the meaning of "Accepted" extends to
the reviewers, so JEP-201 was marked as "Accepted" before the design was
sufficiently complete.   But I also personally have no doubt that once the
design is complete, JEP-201 will be "Accepted".

> Maybe it wouldn't be the worst idea to organize a Jenkins Online Meetup
around JEP concept?

Yes, as noted above, I agree there is still misunderstanding about the JEP
process.  I wouldn't have though to have JOM on this, but maybe we should.
It would be good to highlight that this process exists, talk about when and
how to use it, and so on.  It would probably have to wait until May (April
is looking pretty full already).  In the meanwhile, I still want to update
JEP-1 to clarify

Jesse, Thanks for responding.  You devil's advocate helped me craft the
above response.  Also, do you feel we make it hard to file followup JEPs?

Joseph, Carlos, I hope this response addresses your points.  If not please
say so, and I'll respond specifically.

Thanks,
-Liam

On Fri, Mar 23, 2018 at 8:25 AM Jesse Glick  wrote:

> On Fri, Mar 23, 2018 at 8:11 AM, Carlos Sanchez  wrote:
> > "all 'significant changes' to a JEP should be
> > completed before it is Accepted"  looks like a requirement that may
> hinder
> > innovation and experimentation on areas that are not clear from the
> start.
>
> To play devil’s advocate (I do not have strong feelings about this),
> we should just make it comfortable enough to file follow-up JEPs that
> this is normal practice. A JEP should stay as a Draft until there is a
> clearly working implementation released. Once Accepted, there should
> no eyebrows raised by filing another (initially Draft) JEP like “2018
> refreshes to JEP-234 in light of mistakes made”. That can discuss any
> compatibility issues that might affect early adopters of the original
> version.
>
> --
> 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/CANfRfr0F9z4sXKfZOGU%3D2vtveBt%2BdqReBy%2B4o5tpcwmNTKYEOQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

JEP: Modification of "Accepted" JEPs

[Liam Newman]

We recently had a pull request with a number of significant changes filed
against JEP-201 which has already been "Accepted" (see the JEP workflow
outlined in JEP-1 <https://github.com/jenkinsci/jep/tree/master/jep/1>).

https://github.com/jenkinsci/jep/pull/59

This poses a problem because the JEP workflow doesn't contain guidance for
making/tracking significant changes to JEPs.  The intent of the process is
for all major changes to land while the JEP is a "Draft". A JEP being
"Accepted" means that a general consensus was reached regarding the design
and scope of the component/area described by the JEP.  Once a JEP is marked
"Final", the workflow specifically states that changes should be made by
filing a new JEP and marking the old one as  "Superseded" when the new JEP
is complete.

I would like to add the following clarifications to JEP-1:

   1.  State specifically that all "significant changes" to a JEP should be
   completed before it is Accepted. This is pointed to in a number of places
   but may not be mentioned explicitly.
   2. Define a "significant change" is any change that would modify the
   intent, scope, API, or overall behavior of the component.  I will provide
   some examples.
   3. If "significant changes" are proposed to an "Accepted" JEP, it is be
   the responsibility of the Sponsor to communicate those changes on the
   mailing list and make sure that people have sufficient opportunity to
   review and comment before merging those changes.  A link to the thread
   should be included in the PR for the change and in the References section.
   4. If there are strong objections to the proposed change, the Reviewer
   of the JEP may choose to return the JEP to a "Draft" state for continued
   discussion and re-review.

(Items 1 and 2 are both clarifications. Item 3 is a reiteration of the
existing responsibilities of the JEP Sponsor in light of 1 and 2.  4 is a
reiteration of the existing of responsibilities and powers of the JEP
Review in light of 1 and 2.)

In the case of the above PR. it means that Ewelina would need to start a
thread on the mailing list to discuss this change and give people time to
review before we merge that change.

What do people think of this?  An feedback or suggestions?

Thanks,
Liam Newman
JEP-1 Sponsor

-- 
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/CAA0qCNw8YRNgzrgmasptnJNrPWw0N2M_-Cdo3tBf44cTTqxeDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Liam Newman]

I think it would be interesting to record some metrics around the
complexity of Pipelines, such as cyclomatic complexity and number of lines
in the Jenkinsfile.  If shared libraries are used record the complexity and
size of those.
Also the size of the strings passed to external scripting steps (sh, cmd,
python, powershell, etc).



On Fri, Mar 16, 2018 at 1:41 PM Daniel Beck  wrote:

>
> > On 16. Mar 2018, at 21:28, R. Tyler Croy  wrote:
> >
> > * What are other metrics which would positively impact the development of
> >   Jenkins?
>
> Assuming the Essentials setup allows for whitelisting pipeline methods,
> knowing which methods are whitelisted (or got rejected on whitelisting
> attempt) would be useful to guide improvements of the default whitelist and
> the blacklist.
>
> Basically, INFRA-1285, which I haven't had time to work on.
>
> --
> 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/CEB8092F-4EAD-459B-BE96-FA2946E19B44%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNyn2Wu9gUb1wpbazWtctK9xmcMXdHO164scZ81XNjCu3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

[Liam Newman]

Thanks, James! 

This has been approved as Draft.  Going forward the current version can be 
viewed here:
https://github.com/jenkinsci/jep/blob/master/jep/400/README.adoc

Please continue to discuss in this droup and submit pull requests as 
needed.  

Thanks,
Liam Newman
JEP Editor


On Friday, March 9, 2018 at 2:18:24 AM UTC-8, James Strachan wrote:
>
> I've just submitted a draft of a new JEP: 
> https://github.com/jenkinsci/jep/pull/62
>
> You can read the JEP in full here:
> https://github.com/jstrachan/jep/blob/jx/jep/400/README.adoc
>
> I hope this makes sense & some of you find it interesting. I'd love 
> feedback if anyone has any! 
>
> I'll try blog more about it next week to give a more complete picture of 
> the current functionality in the current prototype. 
>
> -- 
> James
> ---
> Twitter: @jstrachan
> Email: james.s...@gmail.com 
> Blog: https://medium.com/@jstrachan/
>
>

-- 
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/1500b5bd-d320-4551-aa5c-3f2036ea6403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Temporary ownership request for Project Description Setter Plugin

[Liam Newman]

There are less than 2K  installs of this plugin per month.
Perhaps a more reasonable choice would be to End-of-life this plugin?

-L.


On Fri, Jan 12, 2018 at 3:04 PM Daniel Beck  wrote:

>
> > On 12. Jan 2018, at 22:51, Oleg Nenashev  wrote:
> >
> > I would like to temporary take ownership of the plugin and to deliver
> the patch prepared by Jesse. In such case 2000 users of the plugin won't
> hit the issue while updating to new Jenkins versions. After the release I
> will be monitoring the plugin for a couple of months, and I will fix the
> regressions if any.
> >
> > Would everybody be fine with that?
>
> Seems reasonable.
>
> In fact I recommend you limit your responsibility here as much as
> possible, and don't get sucked into doing unrelated changes. So don't call
> it 'temporary ownership', instead 'approval to do a one off release for a
> specific reason'.
>
> --
> 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/EDC2C4BD-E2D8-4F6B-B86C-76C16375A098%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNwrjCSHHM7wuvA7oNnL3taSgB0%2B7cMskfth__fPsBF6CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin idea - declarative pipeline script builder

[Liam Newman]

Sharon,

>From context, it sounds like you're using the Job DSL to create Pipeline
jobs. Is that correct?
Could you share an example of what your code would have to look like
without your tool?

Thanks,
-Liam Newman








On Wed, Jan 3, 2018 at 2:09 PM Jesse Glick <jgl...@cloudbees.com> wrote:

> On Wed, Jan 3, 2018 at 1:50 PM, Sharon Grubner <sharon.grub...@gmail.com>
> wrote:
> > requires all users to know the
> > declarative pipeline syntax
>
> Why not just use the Declarative visual editor in Blue Ocean, for
> users unfamiliar with the syntax?
>
> > does not allow sharing common functions and
> > practices.
>
> You can use Groovy libraries from Declarative, with certain restrictions.
>
> I am not sure I see the point here. If you want to expose a
> programmatic interface to users, then why are you using Declarative at
> all? You can publish libraries for use from Scripted which offer
> reusable functional chunks of all kinds already (including
> “higher-order” functions such as control operators), and this would be
> much more direct as your script would be the Groovy that actually
> runs, rather than a builder that creates a script that is interpreted
> by Declarative to create something to run. Maybe I am just not
> following what your tool actually does.
>
> --
> 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/CANfRfr1_KFxTjnEiddcwZv%3D7jndJvgX%2BgRp%3DUL5DeB5bmx%2B7%3Dg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA0qCNyZGYN5Lmhp8uZh6%3DQjuDd-p0sDz2fWfXUvEzB6fnyPjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The Jenkins Enhancement Process (JEP) is ready for review

[Liam Newman]

JEP-1 has been accepted and is now active. 

Thanks everyone!

On Tuesday, November 7, 2017 at 9:06:03 AM UTC-8, Jesse Glick wrote:
>
> On Fri, Nov 3, 2017 at 6:23 PM, Liam Newman <bitwi...@gmail.com 
> > wrote: 
> > there are still some discussions occurring around some details 
>
> https://github.com/jenkinsci/jep/pull/29 for example. 
>

-- 
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/a1ad42b7-e612-4eea-80e8-ebb37c806016%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The Jenkins Enhancement Process (JEP) is ready for review

[Liam Newman]

Hello all,

I'm pleased to announce the that Jenkins Enhancement Process will be on the 
agenda for governance meeting this coming week.

While there are still some discussions occurring around some details for 
the process, the overall structure seems to have stabilized enough for it 
to be reviewed for Acceptance.

You can review the current state of the proposal in preparation for the 
meeting: https://github.com/jenkinsci/jep/pull/12 .  

Discussion so far:
https://groups.google.com/d/topic/jenkinsci-dev/spDAr8EJm3c/discussion

Thanks, 
-Liam Newman 


-- 
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/bd68913c-3faf-44a4-b52d-4371fafd4af0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

Jesse has pointed out that the process does not say when or how JEPs are 
merged to master.  

There is discussion/proposals needed around what this should look like:
https://github.com/jenkinsci/jep/pull/25


On Tuesday, October 31, 2017 at 10:45:54 AM UTC-7, Liam Newman wrote:
>
> Proposed change to Add an option JIRA header has been merged. 
>
> On Monday, October 30, 2017 at 11:28:29 AM UTC-7, Liam Newman wrote:
>>
>> FYI
>> Jesse has proposed the adding an optional JIRA header.  
>> https://github.com/jenkinsci/jep/pull/21
>>
>> It seems reasonable to me.  Unless there is strong opposition I'll merge 
>> this the main proposal on Wednesday. 
>>
>> Thanks,
>> Liam Newman
>>
>>>
>>>

-- 
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/9b182c4e-aa91-4978-b682-adfaaa3f3431%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Draft JEP: Switch Remoting/XStream blacklist to a whitelist

[Liam Newman]

This submission has been approved as Draft JEP-200. 

 https://github.com/jenkinsci/jep/tree/jep-200


On Monday, October 30, 2017 at 3:10:25 PM UTC-7, Jesse Glick wrote:
>
> After some discussion within the CERT team, I am happy to propose 
>
> https://github.com/jenkinsci/jep/pull/23/files?short_path=b956eee 
>
> as a security hardening measure going forward. 
>
> (Yes I know the JEP process itself has not been formally adopted yet, 
> but I figured it could not hurt to start exercising it.) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2235e6ad-4b66-485b-b405-83aa277fe9ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

Proposed change to Add an option JIRA header has been merged. 

On Monday, October 30, 2017 at 11:28:29 AM UTC-7, Liam Newman wrote:
>
> FYI
> Jesse has proposed the adding an optional JIRA header.  
> https://github.com/jenkinsci/jep/pull/21
>
> It seems reasonable to me.  Unless there is strong opposition I'll merge 
> this the main proposal on Wednesday. 
>
> Thanks,
> Liam Newman
>
>>
>>

-- 
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/220e860c-c835-453e-bb46-d268ff7b4ca6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

FYI
Jesse has proposed the adding an optional JIRA header.  
https://github.com/jenkinsci/jep/pull/21

It seems reasonable to me.  Unless there is strong opposition I'll merge 
this the main proposal on Wednesday. 

Thanks,
Liam Newman


On Friday, October 27, 2017 at 4:33:15 PM UTC-7, Kohsuke Kawaguchi wrote:
>
> Thanks!
>
> On Fri, Oct 27, 2017 at 12:50 PM Liam Newman <bitwi...@gmail.com 
> > wrote:
>
>> Updates:
>>
>>- All proposed changes have been merged
>>- BDFL Delegates are fully described
>>- Governance meeting has oversight of BDFL
>>- Added JEP Template to the PR
>>
>> https://github.com/jenkinsci/jep/pull/12 is now fully up-to-date and 
>> comments made so far have been addressed.
>>
>> I believe JEP-1 is on the agenda for the next governance meeting.  Please 
>> review the PR and any propose fixes/changes now. 
>>
>>
>> On Tuesday, October 24, 2017 at 7:08:47 PM UTC-7, Liam Newman wrote:
>>>
>>> There's been quiet a bit of discussion offline about this
>>> I've closed #18 as Kohsuke's objections to it make it a non-starter. 
>>>
>>> I've instead opened
>>> * https://github.com/jenkinsci/jep/pull/19 that restores BDFL delegates
>>> * https://github.com/bitwiseman/jep/pull/1 proposed amendment to #19 
>>> that adds Governance meeting oversight of BDFL.
>>>
>>> Comments welcome, PR's with proposed fixes preferred.  
>>>
>>>
>>> On Friday, October 20, 2017 at 11:08:27 AM UTC-7, Kohsuke Kawaguchi 
>>> wrote:
>>>>
>>>> I admit I kept my eyes off this ball for a while. Naturally, I'm 
>>>> surprised at this change.
>>>>
>>>> My understanding was that this change is being considered as a reaction 
>>>> to those two concerns:
>>>>
>>>> > 1. Kohsuke as the BDFL introduces a problematic bottleneck to the 
>>>> process
>>>> >(there are way more of us, than there are of him).
>>>> >
>>>> > 2. JEP-1 introduces a different way of decision making than has been
>>>> >traditionally followed with the Governance Meeting
>>>> >(https://jenkins.io/project/governance/#meeting)
>>>>
>>>> I prefer the original "BDFL + Delegate" model. I'd like to explain the 
>>>> reasons, and why that model adequately address those concerns. This is 
>>>> going to be a long post.
>>>>
>>>>
>>>> First, the bottleneck point. As Bobby said in this thread and was 
>>>> discussed in the contributor summit, I understood my role in this process 
>>>> to be more like British Queen or Japanese Emperor, in the sense that I'm 
>>>> expected to designate Delegate in each area and let them lead those areas, 
>>>> as opposed to Supreme Court Justice who preside over individual cases. 
>>>> That 
>>>> is, the idea is to influence Delegates instead of influencing JEPs. In 
>>>> this 
>>>> manner, I don't think BDFL will be a bottleneck.
>>>>
>>>> The obvious question then would be how I pick Delegate. I think most 
>>>> area has natural leads that owns the spaces. For example, Daniel leads 
>>>> security related things, Oleg leads remoting, Jesse leads Pipeline, and so 
>>>> on. Those people currently have implicit influences, and we know who they 
>>>> are. I intend to designate them as Delegate. I will discuss that 
>>>> designation beforehand to eliminate any chance of surprises.
>>>>
>>>> This brings me to one of the reasons why I'm supporting JEP. Today, 
>>>> people who lead various efforts do so solely based on implicit influence. 
>>>> But this scheme doesn't work well as we scale up. I see the Delegate title 
>>>> as a way to make those implicit influences more explicit, so that people 
>>>> who are not spending as much time in the project or contributors from 
>>>> organizations can easily identify them as the primary go-to guy. Put 
>>>> differently, I want the Delegate title to help those people lead more 
>>>> effectively. The officer title worked very well with this regard. I think 
>>>> of Delegate as technical version of it. Obviously, we don't want Delegate 
>>>> to be dictators any more than you want BDFL to be actual dictator.And that 
>>>> spirit is captured in JEP. We expect Delegate to understand implicit 
>>>> influences of other people in neighboring areas

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

Updates:

   - All proposed changes have been merged
   - BDFL Delegates are fully described
   - Governance meeting has oversight of BDFL
   - Added JEP Template to the PR

https://github.com/jenkinsci/jep/pull/12 is now fully up-to-date and 
comments made so far have been addressed.

I believe JEP-1 is on the agenda for the next governance meeting.  Please 
review the PR and any propose fixes/changes now. 


On Tuesday, October 24, 2017 at 7:08:47 PM UTC-7, Liam Newman wrote:
>
> There's been quiet a bit of discussion offline about this
> I've closed #18 as Kohsuke's objections to it make it a non-starter. 
>
> I've instead opened
> * https://github.com/jenkinsci/jep/pull/19 that restores BDFL delegates
> * https://github.com/bitwiseman/jep/pull/1 proposed amendment to #19 that 
> adds Governance meeting oversight of BDFL.
>
> Comments welcome, PR's with proposed fixes preferred.  
>
>
> On Friday, October 20, 2017 at 11:08:27 AM UTC-7, Kohsuke Kawaguchi wrote:
>>
>> I admit I kept my eyes off this ball for a while. Naturally, I'm 
>> surprised at this change.
>>
>> My understanding was that this change is being considered as a reaction 
>> to those two concerns:
>>
>> > 1. Kohsuke as the BDFL introduces a problematic bottleneck to the 
>> process
>> >(there are way more of us, than there are of him).
>> >
>> > 2. JEP-1 introduces a different way of decision making than has been
>> >traditionally followed with the Governance Meeting
>> >(https://jenkins.io/project/governance/#meeting)
>>
>> I prefer the original "BDFL + Delegate" model. I'd like to explain the 
>> reasons, and why that model adequately address those concerns. This is 
>> going to be a long post.
>>
>>
>> First, the bottleneck point. As Bobby said in this thread and was 
>> discussed in the contributor summit, I understood my role in this process 
>> to be more like British Queen or Japanese Emperor, in the sense that I'm 
>> expected to designate Delegate in each area and let them lead those areas, 
>> as opposed to Supreme Court Justice who preside over individual cases. That 
>> is, the idea is to influence Delegates instead of influencing JEPs. In this 
>> manner, I don't think BDFL will be a bottleneck.
>>
>> The obvious question then would be how I pick Delegate. I think most area 
>> has natural leads that owns the spaces. For example, Daniel leads security 
>> related things, Oleg leads remoting, Jesse leads Pipeline, and so on. Those 
>> people currently have implicit influences, and we know who they are. I 
>> intend to designate them as Delegate. I will discuss that designation 
>> beforehand to eliminate any chance of surprises.
>>
>> This brings me to one of the reasons why I'm supporting JEP. Today, 
>> people who lead various efforts do so solely based on implicit influence. 
>> But this scheme doesn't work well as we scale up. I see the Delegate title 
>> as a way to make those implicit influences more explicit, so that people 
>> who are not spending as much time in the project or contributors from 
>> organizations can easily identify them as the primary go-to guy. Put 
>> differently, I want the Delegate title to help those people lead more 
>> effectively. The officer title worked very well with this regard. I think 
>> of Delegate as technical version of it. Obviously, we don't want Delegate 
>> to be dictators any more than you want BDFL to be actual dictator.And that 
>> spirit is captured in JEP. We expect Delegate to understand implicit 
>> influences of other people in neighboring areas and bring them in as 
>> appropriate.
>>
>> One of the problems I have with the proposed self-nominated Reviewer 
>> scheme is that it does not help with this regard. There's no explicit title 
>> like "Delegate" to clarify the role of leads. Those leads still need to 
>> rely solely on implicit influences.
>>
>>
>> Back to how to pick Delegate. When we start a new effort, in the area 
>> where there's no existing effort, say Jenkins 2 or pluggable storage, I 
>> expect the initial JEP to capture goals and high level requirements of that 
>> effort. I will be the reviewer of that initial JEP, but as a part of that 
>> JEP I expect the Delegate to be determined for that space. Oftentimes the 
>> sponsor of that JEP should be the obvious choice as the Delegate as the 
>> leader of the effort. Other times we may need to have more discussions 
>> among the core developers to determine that person. Subsequent JEP in that 
>> space, to the extent it stays within the 

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

 lead those efforts have limited visibility in the 
> project. This came up multiple times in my conversation with potential 
> corporate contributors outside CloudBees.
>
> One of the problems I have with the removal of Delegate is that we lose 
> the tool to help make this authority explicit. And likewise, we lose the 
> continuity of Delegate. I hope we will have a lot of different Sponsors 
> trying to drive changes in the same area, and we need Delegate ensures that 
> there's some consistency and continuity, which requires a stable Delegate.
>
>
> As for the second concern of the decision making structure outside the 
> governance meeting, I think what I'm describing above is very much in line 
> with how we have been operating on technical matters. We never really used 
> the governance meeting as a venue for technical decision making, and that's 
> the way I think it should be. It obviously provides a great place for 
> synchronous communication to bring people to some consensus faster, like 
> new LTS base version, but only a specific subset of people who work on 
> Jenkins are there.
>
> One of my goals in JEP is to clarify the path of technical decision 
> making. The original proposal does this by symbolically rooting the chain 
> of authority to BDFL (like how Queen and Emperor symbolically empowers the 
> elected government.) The removal of BDFL + Delegate tries to root the chain 
> of authority to "consensus of core contributors", but that fails to achieve 
> this goal because "core contributors" is not a group with clear boundary, 
> and we don't know how far "consensus" needs to be reached.
>
>
> So there it is. I argue we should accept #12 
> <https://github.com/jenkinsci/jep/pull/12> without #18 
> <https://github.com/jenkinsci/jep/pull/18>.
>
> On Wed, Oct 18, 2017 at 4:45 PM Liam Newman <bitwi...@gmail.com 
> > wrote:
>
>> In the latest change, I've proposed removing the BDFL role.
>> https://github.com/jenkinsci/jep/pull/18 to see the changes.
>>
>> (Note: in a previous PR I replaced the BDFL-delegate role with a 
>> "Reviewer" role and had expanded the description of BDFL.)
>>
>> I got it this far, but I'm out of bandwidth to make further changes this 
>> week.
>> Oleg had some valid questions, and said he'd try to submit a PR 
>> addressing them.
>> If anyone else wants to pick up a little of the load here, that'd be 
>> great - comments welcome, PRs preferred. 
>>
>> Thanks,
>> Liam Newman
>>
>>
>>
>>
>>
>> On Tuesday, September 19, 2017 at 10:12:29 AM UTC-7, R Tyler Croy wrote:
>>
>>> (replies inline) 
>>>
>>> On Wed, 13 Sep 2017, R. Tyler Croy wrote: 
>>>
>>> > https://github.com/jenkinsci/jep/tree/jep-1/jep/1 
>>>
>>>
>>> Since I'm sure not everybody has been following along with some of the 
>>> pull 
>>> requests and changes while we've been hammering out JEP-1, I would like 
>>> to 
>>> provide a little bit of an update and solicit some help. This topic is 
>>> very 
>>> important, so please read this email! 
>>>
>>> First, thanks to reviews from a number of folks including Oleg, Owen, 
>>> Daniel, 
>>> and others, we have been able to tighten the proposal up quite a bit. 
>>> Mostly 
>>> thanks to Liam's diligent slicing and dicing of text :) 
>>>
>>> While I had hoped we might be able to get some consensus in time for 
>>> tomorrow's 
>>> project meeting, I don't think we are quite there yet. There has been 
>>> lots of 
>>> helpful feedback on the review and decision-making process 
>>> (BDFL/BDFL-delegate): 
>>> https://github.com/jenkinsci/jep/tree/jep-1/jep/1#review 
>>>
>>>
>>> To summarize the primary, and valid, criticisms if I may: 
>>>
>>>  1. Kohsuke as the BDFL introduces a problematic bottleneck to the 
>>> process 
>>> (there are way more of us, than there are of him). 
>>>
>>>  2. JEP-1 introduces a different way of decision making than has been 
>>> traditionally followed with the Governance Meeting 
>>> (https://jenkins.io/project/governance/#meeting) 
>>>
>>>
>>> I would like to guide the discussion towards addressing these. I also 
>>> want to 
>>> ensure our process is sensitive to contributors around the world, 
>>> especially 
>>> those in Australia and Asia who are typically asleep during the 
>>> scheduled 
>>> proj

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

In the latest change, I've proposed removing the BDFL role.
https://github.com/jenkinsci/jep/pull/18 to see the changes.

(Note: in a previous PR I replaced the BDFL-delegate role with a "Reviewer" 
role and had expanded the description of BDFL.)

I got it this far, but I'm out of bandwidth to make further changes this 
week.
Oleg had some valid questions, and said he'd try to submit a PR addressing 
them.
If anyone else wants to pick up a little of the load here, that'd be great 
- comments welcome, PRs preferred. 

Thanks,
Liam Newman





On Tuesday, September 19, 2017 at 10:12:29 AM UTC-7, R Tyler Croy wrote:
>
> (replies inline) 
>
> On Wed, 13 Sep 2017, R. Tyler Croy wrote: 
>
> > https://github.com/jenkinsci/jep/tree/jep-1/jep/1 
>
>
> Since I'm sure not everybody has been following along with some of the 
> pull 
> requests and changes while we've been hammering out JEP-1, I would like to 
> provide a little bit of an update and solicit some help. This topic is 
> very 
> important, so please read this email! 
>
> First, thanks to reviews from a number of folks including Oleg, Owen, 
> Daniel, 
> and others, we have been able to tighten the proposal up quite a bit. 
> Mostly 
> thanks to Liam's diligent slicing and dicing of text :) 
>
> While I had hoped we might be able to get some consensus in time for 
> tomorrow's 
> project meeting, I don't think we are quite there yet. There has been lots 
> of 
> helpful feedback on the review and decision-making process 
> (BDFL/BDFL-delegate): 
> https://github.com/jenkinsci/jep/tree/jep-1/jep/1#review 
>
>
> To summarize the primary, and valid, criticisms if I may: 
>
>  1. Kohsuke as the BDFL introduces a problematic bottleneck to the process 
> (there are way more of us, than there are of him). 
>
>  2. JEP-1 introduces a different way of decision making than has been 
> traditionally followed with the Governance Meeting 
> (https://jenkins.io/project/governance/#meeting) 
>
>
> I would like to guide the discussion towards addressing these. I also want 
> to 
> ensure our process is sensitive to contributors around the world, 
> especially 
> those in Australia and Asia who are typically asleep during the scheduled 
> project meetings and rely on asynchronous mediums like email. 
>
> If you have an example structure for technical decision-making from 
> another 
> project, which you think is applicable, please chime in! 
>
>
> Personally, what I'm thinking right now is to flip the Python model upside 
> down: when the JEP Author creates a draft they (or a JEP Editor) list a 
> "Delegate" who would be somebody with good standing as the maintainer of 
> that 
> subject area, other than themselves. 
>
> For example, if I were proposing a design on Remoting, Oleg would be the 
> obvious Delegate. If Andrew were proposing some design around Pipeline, 
> Jesse 
> would be a reasonable Delegate. Rather than expecting a BDFL to be 
> "plugged 
> into" each JEP, we self-select more (which I think we're all capable of 
> doing). 
> For the times when we might have conflcit, then we can use the Governance 
> Meeting process to resolve who the appropriate Delegate for a proposal may 
> be. 
> To help new comers, including a list of "Suggested Delegates" in the JEP 
> repo 
> could also be helpful. 
>
> I think that could avoid the problems with the current BDFL proposal, 
> while 
> reducing the need to run every JEP through the Governance Meeting process, 
> where not all the stakeholders will necessarily be present. 
>
>
>
> Of course, I'm open to more suggestions and discussion. Like I said at the 
> beginning of the email, I think getting this right is important. 
>
>
> Cheers 
> - R. Tyler Croy 
>
> -- 
>  Code: <https://github.com/rtyler> 
>   Chatter: <https://twitter.com/agentdero> 
>  xmpp: rty...@jabber.org  
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F 
> -- 
>

-- 
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/78ac83c8-6290-41f9-98f9-7e977ec6004b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Liam Newman]

I think this is great idea. I agree with the proposed process.
 
I think the proposal document itself could use some tweaks, which I've 
suggested in PR (oops oh well). 


On Wednesday, September 13, 2017 at 12:33:04 PM UTC-7, R Tyler Croy wrote:
>
> At the Jenkins World Contributor Summit a couple weeks ago, I shared some 
> thoughts I have been having on how we can continue to grow and improve 
> Jenkins. 
> One of those thoughts centers around the fundamental challenge: how do we, 
> as a 
> group, make large transformational changes to Jenkins (and still get along 
> and 
> like each other during the process). 
>
> Python users may recognize this structure, which is how the Python 
> community 
> has organized their work. PEP in the Python community has allowed Python 
> to 
> make *massive* changes over the past 15 years to what Python is, without 
> killing each other (very important). 
>
>
> I would like to propose the following process of a "Jenkins Enhancement 
> Proposal": 
>
> https://github.com/jenkinsci/jep/tree/jep-1/jep/1 
>
>
> The overarching rationale for this proposal can be found in the rationale 
> section: https://github.com/jenkinsci/jep/tree/jep-1/jep/1#rationale 
>
> I also created an example of an Informational JEP here: 
> https://github.com/jenkinsci/jep/pull/2 
>
>
> For discussion on this foundational JEP, I suggest using this mailing list 
> thread. To propose changes, or fix some verbiage, feel free to open a pull 
> request targeting that `jep-1` branch. 
>
>
> To agree to this change in process, I don't think a "BDFL" or 
> "BDFL-Delegate" 
> approval itself (read the doc) is sufficient. I think we should try to 
> reach 
> consensus on this thread, and assuming there's consensus, approve the 
> proposal 
> during the next Governance Meeting (Sept 27th). 
>
>
> Feel free to ping me via email or IRC if you have questions which you do 
> not 
> feel belong in the mailing list discussion. 
>
>
> Thank you in advance for spending the time to read JEP-1 :) 
>
>
> Cheers 
> - R. Tyler Croy 
>
> -- 
>  Code:  
>   Chatter:  
>  xmpp: rty...@jabber.org  
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F 
> -- 
>

-- 
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/95e20056-7e89-4233-9a74-67522d0ea549%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: State of Xcode plugin??

[Liam Newman]

There is a process for these situation, but when did you contact them? 
 Maintainers are often busy, 

Have you created issues and/or submitted pull requests to fix existing 
issues?


On Tuesday, September 6, 2016 at 10:37:33 AM UTC-7, Brantone wrote:
>
> Curious as to the current state of Xcode plugin. Although there was a 
> recent merge last month, there hasn't been a release in almost a year and a 
> list of PRs piling up.
> I've attempted to contact current maintainer about helping out, but have 
> not heard word back.
> Is there a process for such a situation??
> With changes in Jenkins 2.x and Xcode 8, would be a shame for the plugin 
> to get further behind.
>
> Cheers
>

-- 
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/9c4d9514-eaf8-4ffd-8210-b33704ae2e5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Tests Memory Usage (Maybe jenkins rule)

[Liam Newman]

Take a look at https://github.com/jenkinsci/git-plugin/pull/411 again.  

I tried _reducing_ the size of the heap and Mark increased the size of the 
PermGen for Java 7.
Note: we had to do this for both Surefire and the parent Maven process 
separately. 
This resulted in a stable environment with lower memory requirements.

https://ci.jenkins.io/job/Plugins/job/git-plugin/job/3.0.0-beta/


On Wednesday, July 27, 2016 at 3:02:46 PM UTC-7, Liam Newman wrote:
>
> So, we're getting inconsistent behavior, but definitely still seeing out 
> of memory errors.  Correct? 
>
>
> On Tuesday, July 19, 2016 at 12:11:33 AM UTC-7, Gavin Mogan wrote:
>>
>> Across the board, openjdk 7, Oracle 7, Java 8
>>
>> After adding the perm size and concurrency I still have 100℅ fail on Java 
>> 8 but 7 often passes. At least on travis
>>
>> On Jul 19, 2016 12:07 AM, "Daniel Beck" <m...@beckweb.net> wrote:
>>
>>> To clarify, are you observing the original problem on Java 8 as well, or 
>>> just the MaxPermSize message?
>>>
>>> > On 18.07.2016, at 22:13, Gavin Mogan <ga...@gavinmogan.com> wrote:
>>> >
>>> > I take that back. While that works great on java 7, it fails on java 8
>>> >
>>> > 
>>> https://travis-ci.org/saucelabs/jenkins-sauce-ondemand-plugin/jobs/145615483
>>> >
>>> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
>>> MaxPermSize=380m; support was removed in 8.0
>>> >
>>> > Since its now running on java 7, and the target is currently java 7, 
>>> i'm okay with disabling 8 for now on travis.
>>> >
>>> > This fix to me indicates there's a bigger problem though, and I have 
>>> no idea what that might be or where to even start.
>>> >
>>> > On Mon, Jul 18, 2016 at 11:20 AM, Gavin Mogan <ga...@gavinmogan.com> 
>>> wrote:
>>> > Oh wow, that went from not being able to finish in 10 minutes for one 
>>> test file, to be able to run the entire suite in 3 minutes.
>>> >
>>> > That fixes a lot of issues! thanks!
>>> >
>>> >
>>> > On Mon, Jul 18, 2016 at 2:09 AM, Robert Sandell <rsan...@cloudbees.com> 
>>> wrote:
>>> > I had to tweak my pom settings when I switched to the new parent pom 
>>> because the slaves that the standard plugin builds run on are 2 cores with 
>>> 2 GB RAM and my original settings were too big for that when running in 
>>> parallel.
>>> >
>>> > 
>>> https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/pom.xml#L60
>>> > 
>>> https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/pom.xml#L224
>>> >
>>> > /B
>>> >
>>> >
>>> > On Fri, Jul 15, 2016 at 11:09 PM, Liam Newman <bitwi...@gmail.com> 
>>> wrote:
>>> > I'm hitting a similar issue when trying to run tests in parallel for 
>>> the git-plugin:
>>> >
>>> > https://github.com/jenkinsci/git-plugin/pull/411
>>> > https://ci.jenkins.io/job/Plugins/job/git-plugin/job/3.0.0-beta/20/
>>> >
>>> > This thread suggests that is might be possible to set the memory limit 
>>> on the surefile JVM.  I'll try that now:
>>> > https://groups.google.com/forum/#!topic/jenkinsci-dev/V3wLEbDR2Sw
>>> >
>>> >
>>> >
>>> > --
>>> > 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-de...@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/94a4dc8d-7ca8-462a-a648-c08fad8ec9aa%40googlegroups.com
>>> .
>>> >
>>> > For more options, visit https://groups.google.com/d/optout.
>>> >
>>> >
>>> >
>>> > --
>>> > Robert Sandell
>>> > Software Engineer
>>> > CloudBees Inc.
>>> >
>>> > --
>>> > 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/OccFatOc9A8/unsubscribe.
>>> > To unsubscribe from this group and all its topics, send an email to 
>>> jenkinsci-de...@googlegr

Re: Plugin Tests Memory Usage (Maybe jenkins rule)

[Liam Newman]

So, we're getting inconsistent behavior, but definitely still seeing out of 
memory errors.  Correct? 


On Tuesday, July 19, 2016 at 12:11:33 AM UTC-7, Gavin Mogan wrote:
>
> Across the board, openjdk 7, Oracle 7, Java 8
>
> After adding the perm size and concurrency I still have 100℅ fail on Java 
> 8 but 7 often passes. At least on travis
>
> On Jul 19, 2016 12:07 AM, "Daniel Beck" <m...@beckweb.net > 
> wrote:
>
>> To clarify, are you observing the original problem on Java 8 as well, or 
>> just the MaxPermSize message?
>>
>> > On 18.07.2016, at 22:13, Gavin Mogan <ga...@gavinmogan.com 
>> > wrote:
>> >
>> > I take that back. While that works great on java 7, it fails on java 8
>> >
>> > 
>> https://travis-ci.org/saucelabs/jenkins-sauce-ondemand-plugin/jobs/145615483
>> >
>> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
>> MaxPermSize=380m; support was removed in 8.0
>> >
>> > Since its now running on java 7, and the target is currently java 7, 
>> i'm okay with disabling 8 for now on travis.
>> >
>> > This fix to me indicates there's a bigger problem though, and I have no 
>> idea what that might be or where to even start.
>> >
>> > On Mon, Jul 18, 2016 at 11:20 AM, Gavin Mogan <ga...@gavinmogan.com 
>> > wrote:
>> > Oh wow, that went from not being able to finish in 10 minutes for one 
>> test file, to be able to run the entire suite in 3 minutes.
>> >
>> > That fixes a lot of issues! thanks!
>> >
>> >
>> > On Mon, Jul 18, 2016 at 2:09 AM, Robert Sandell <rsan...@cloudbees.com 
>> > wrote:
>> > I had to tweak my pom settings when I switched to the new parent pom 
>> because the slaves that the standard plugin builds run on are 2 cores with 
>> 2 GB RAM and my original settings were too big for that when running in 
>> parallel.
>> >
>> > 
>> https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/pom.xml#L60
>> > 
>> https://github.com/jenkinsci/gerrit-trigger-plugin/blob/master/pom.xml#L224
>> >
>> > /B
>> >
>> >
>> > On Fri, Jul 15, 2016 at 11:09 PM, Liam Newman <bitwi...@gmail.com 
>> > wrote:
>> > I'm hitting a similar issue when trying to run tests in parallel for 
>> the git-plugin:
>> >
>> > https://github.com/jenkinsci/git-plugin/pull/411
>> > https://ci.jenkins.io/job/Plugins/job/git-plugin/job/3.0.0-beta/20/
>> >
>> > This thread suggests that is might be possible to set the memory limit 
>> on the surefile JVM.  I'll try that now:
>> > https://groups.google.com/forum/#!topic/jenkinsci-dev/V3wLEbDR2Sw
>> >
>> >
>> >
>> > --
>> > 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-de...@googlegroups.com .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/94a4dc8d-7ca8-462a-a648-c08fad8ec9aa%40googlegroups.com
>> .
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> > --
>> > Robert Sandell
>> > Software Engineer
>> > CloudBees Inc.
>> >
>> > --
>> > 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/OccFatOc9A8/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-de...@googlegroups.com .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0vFmVVxovbEE35D9KJLoR5sVsvCqtCnhePAi-wF%2B2iQw%40mail.gmail.com
>> .
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> > --
>> > 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-de...@googlegroups.com .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duvs4%3DRMzq8-NGoQXC_sSStGcU6KzrJWVNi79v2D2Mdn-A%40mail.gmail.com
>> .
&g

PR needs review: job-dsl-plugin #880

[Liam Newman]

Fixes snippet generator compatibility in jobDSL step.

https://github.com/jenkinsci/job-dsl-plugin/pull/880

It's been close to 2 weeks since I opened this.  Any feedback appreciated. 
Thanks!
Liam Newman


-- 
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/665f2668-2f52-4aef-92ea-0777bc555604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable Travis CI for jenkins plugin repo

[Liam Newman]

Andrey, 
What does running in TravisCI provide that is not already in the 
jenkinsci.org build?  Just wondering.

Thanks!
Liam Newman

-- 
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/dd684a61-61cd-4d8e-bbf7-c7965949e32e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.