March 15th, 2021 Community Meeting

[qu1queee]

• Please add a topic in this thread and add a link to the Github issue associated with the topic.
• Please make sure you give folks enough time to review/discuss the topic offline on Github before coming into the meeting
• (optional) Paste the image of an animal 😸

[imjasonh]

• timing out git validation (off by default?) (Git source validation will be stuck in some cases which causes a pile up of unregistered build objects #659)
• ClusterBuildStrategy support and default .strategy.kind (Change StrategyRef strategy kind default behaviour #657)
• runtime image use cases and future support (off by default?) (Runtime Image Support #263)
• Rebase BuildStrategy (WIP: Rebase BuildStrategy #656)
• Pig in rain boots ☔
  

[zhangtbj]

• Nightly release list (How Tekton store the nightly release?) and how to use it for issue Simplify the "Try it" section #498 (comment)

[mattcui]

• Propose to remove workingDir setting from kaniko buildstrategy Propose to remove workingDir setting from kaniko buildstrategy #658

[qu1queee]

PR 652 what is this? from where is this coming? is this ready for review? and relationship with PR 616

Here a confused English Springer Spaniel!

[adambkaplan]

GitHub Project Boards for Shipwright

[imjasonh]

• Nightly release list (How Tekton store the nightly release?) and how to use it for issue #498 (comment)

• Stable name: Produce nightly.yaml release YAML with stable name #664
• Prune old nightlies: Prune old nightly releases #665

[qu1queee]

Community meeting minutes:

• @imjasonh brought a list of different issues where feedback is more than welcome, see comment. We discussed in detail the "Rebase BuildStrategy" feature,
• @zhangtbj provided some question on the nightly release setup, which led to March 15th, 2021 Community Meeting #660 (comment)
• @mattcui provided insights on a change for the Kaniko strategy, in order to improve the user experience March 15th, 2021 Community Meeting #660 (comment). The issue will remain open for feedback.
• @adambkaplan mentioned on Project Boards as an optional for managing our multiple backlogs (build,cli,website).

I´m leaving the outcome of our discussion around breaking changes as an open one, so that more people can provide some feedback(what was said, concerns, etc) on what we discussed.

[qu1queee]

From my side around breaking changes, these are my main key points from what was discussed in the meeting:

• As a shipwright contributor I want understand how are we proposing breaking changes and to see if we could get more transparency on the rational behind them. I provided some examples on existing pull requests where the use case is not clear to me and I asked for new ways to provide more data on why they are needed. I also provided some evidence on some changes being proposed contradicting to each other, e.g. spec.inputs vs spec.sources. Note: This does not equal resistance, on the contrary I´m looking forward for changes that can address N scenarios

• As a shipwright contributor I want to ensure we aim for a well defined v1.0.0 milestone list of items. I think we have the right things in place to address this , e.g. milestones, grooming session, mailing list. Note: If we agree we want to keep breaking changes as minimal after v1.0.0 (Stable API), then we need to work towards this goal.

All of the above are my personal opinions.

[adambkaplan]

/close

[openshift-ci-robot]

@adambkaplan: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.