2020-07-08-june-status-update.org (5554B)
1 #+title: Status update, June 2020 2 #+date: <2020-07-08 Wed> 3 #+filetags: status update 4 #+setupfile: ../templates/post.org 5 6 * Introduction 7 8 Time for the first new monthly status update! I do like those updates from [[https://drewdevault.com/2020/06/15/Status-update.html][Drew DeVault]] 9 and [[https://emersion.fr/blog/2020/status-update-19/][Simon Ser]], so I figured, why not trying myself 🙃. I am not sure where to start and 10 where to end, but I guess I'll figure things out as I go. 11 12 * Tekton & OpenShift Pipelines 13 14 As you know, /or may not/, I am working on the [[https://github.com/tektoncd/][TektonCD]] project and also on our [[https://redhat.com][RedHat]] 15 product [[https://www.openshift.com/learn/topics/pipelines][OpenShift Pipelines]]. As far as the month of June went : 16 17 - We release [[https://github.com/tektoncd/pipeline/releases/tag/v0.13.0][v0.13.0]] "Bobtail Bishop" and a bunch of fixes ([[https://github.com/tektoncd/pipeline/releases/tag/v0.13.2][v0.13.2]]) 18 + It's the second release after the =v1beta1= bump, and we start to stabilise things. 19 + [[https://github.com/tektoncd/pipeline/releases/tag/v0.14.0][v0.14.0]] will (and actually is already) a more feature-packed release because there is 20 now the =finally= field support and cloud-events opt-in. 21 - But the *most important* contributions I tried to make during that month is the TEP 22 process. *TEP* stands for *Tekton Enhancement proposals*. 23 24 #+begin_src markdown 25 # Tekton Enhancement Proposals (TEPs) 26 27 A Tekton Enhancement Proposal (TEP) is a way to propose, communicate 28 and coordinate on new efforts for the Tekton project. You can read 29 the full details of the project in 30 [TEP-1](https://github.com/tektoncd/community/blob/master/teps/0001-tekton-enhancement-proposal-process.md). 31 32 ## What is a TEP 33 34 A standardized development process for Tekton is proposed in order to 35 36 - provide a common structure and clear checkpoints for proposing 37 changes to Tekton 38 - ensure that the motivation for a change is clear 39 - allow for the enumeration stability milestones and stability 40 graduation criteria 41 - persist project information in a Version Control System (VCS) for 42 future Tekton users and contributors 43 - support the creation of _high value user facing_ information such 44 as: 45 - an overall project development roadmap 46 - motivation for impactful user facing changes 47 - ensure community participants are successfully able to drive changes 48 to completion across one or more releases while stakeholders are 49 adequately represented throughout the process 50 51 This process is supported by a unit of work called a Tekton 52 Enhancement Proposal (TEP). A TEP attempts to combine aspects of the 53 following: 54 55 - feature, and effort tracking document 56 - a product requirements document 57 - design document 58 59 into one file which is created incrementally in collaboration with one 60 or more [Working 61 Groups](https://github.com/tektoncd/community/blob/master/working-groups.md) 62 (WGs). 63 64 This process does not block authors from doing early design docs using 65 any means. It does not block authors from sharing those design docs 66 with the community (during Working groups, on Slack, GitHub, …. 67 68 ,**This process acts as a requirement when a design docs is ready to be 69 implemented or integrated in the `tektoncd` projects**. In other words, 70 a change that impact other `tektoncd` projects or users cannot be 71 merged if there is no `TEP` associated with it. 72 73 This TEP process is related to 74 - the generation of an architectural roadmap 75 - the fact that the what constitutes a feature is still undefined 76 - issue management 77 - the difference between an accepted design and a proposal 78 - the organization of design proposals 79 80 This proposal attempts to place these concerns within a general 81 framework. 82 83 84 See [TEP-1](https://github.com/tektoncd/community/blob/master/teps/0001-tekton-enhancement-proposal-process.md) for more details. 85 #+end_src 86 87 * =home=, Nixos and the rest of thing 88 89 I did some big changes in my [[https://git.sr.ht/~vdemeester/home][=home=]] repository, it's still much a work-in-progress but it 90 is in a way better state than before. 91 92 - It is more reproductible. All dependencies are managed by [[https://github.com/nmattia/niv][niv]] and all machines are using 93 a pinned version of channels from there. That way I can test the configuration (on the 94 CI) and cache the packages for all channels that my machines uses. I also can decide 95 when I want to upgrade a particular channel (nixos, unstable, …). 96 - I am slowly experimenting on simplifying things more and more. This is a bit related to 97 the [[file:2020-02-22-digital-minimalism.org][previous post]]. I am trying to use Gnome3 everywhere. Well configured, managed by 98 NixOS, it's enough for my test and reduce the configuration cruft I need to do. 99 100 An ongoing work is my knowledge base and how it is published as part of this website : 101 [[https://vincent.demeester.fr/articles/][articles]]. I am trying to make all those publishable (for the one that do not hold any 102 secret). I'll document this a bit more at some point but… 103 - Configurations are now part of that knowledge base, the =docs= folder of [[https://git.sr.ht/~vdemeester/home][=home=]] is going 104 away. 105 - I am trying to use litterate configuration as much as possible. So slowly, the content 106 from [[https://git.sr.ht/~vdemeester/home][=home=]] will be a tangled version of my knowledge base. At least that is the goal as 107 of today. 108 109 And I feel that's all /for June/.