Status update, June 2020

Introduction

Time for the first new monthly status update! I do like those updates from Drew DeVault and Simon Ser, so I figured, why not trying myself 🙃. I am not sure where to start and where to end, but I guess I’ll figure things out as I go.

Tekton & OpenShift Pipelines

As you know, or may not, I am working on the TektonCD project and also on our RedHat product OpenShift Pipelines. As far as the month of June went :

  • We release v0.13.0 “Bobtail Bishop” and a bunch of fixes (v0.13.2)
    • It’s the second release after the v1beta1 bump, and we start to stabilise things.
    • v0.14.0 will (and actually is already) a more feature-packed release because there is now the finally field support and cloud-events opt-in.
  • But the most important contributions I tried to make during that month is the TEP process. TEP stands for Tekton Enhancement proposals.

    # Tekton Enhancement Proposals (TEPs)
    
    A Tekton Enhancement Proposal (TEP) is a way to propose, communicate
    and coordinate on new efforts for the Tekton project.  You can read
    the full details of the project in
    [TEP-1](https://github.com/tektoncd/community/blob/master/teps/0001-tekton-enhancement-proposal-process.md).
    
    ## What is a TEP
    
    A standardized development process for Tekton is proposed in order to
    
    - provide a common structure and clear checkpoints for proposing
      changes to Tekton
    - ensure that the motivation for a change is clear
    - allow for the enumeration stability milestones and stability
      graduation criteria
    - persist project information in a Version Control System (VCS) for
      future Tekton users and contributors
    - support the creation of _high value user facing_ information such
      as:
      - an overall project development roadmap
      - motivation for impactful user facing changes
    - ensure community participants are successfully able to drive changes
      to completion across one or more releases while stakeholders are
      adequately represented throughout the process
    
    This process is supported by a unit of work called a Tekton
    Enhancement Proposal (TEP). A TEP attempts to combine aspects of the
    following:
    
    - feature, and effort tracking document
    - a product requirements document
    - design document
    
    into one file which is created incrementally in collaboration with one
    or more [Working
    Groups](https://github.com/tektoncd/community/blob/master/working-groups.md)
    (WGs).
    
    This process does not block authors from doing early design docs using
    any means. It does not block authors from sharing those design docs
    with the community (during Working groups, on Slack, GitHub, ….
    
    **This process acts as a requirement when a design docs is ready to be
    implemented or integrated in the `tektoncd` projects**. In other words,
    a change that impact other `tektoncd` projects or users cannot be
    merged if there is no `TEP` associated with it.
    
    This TEP process is related to
    - the generation of an architectural roadmap
    - the fact that the what constitutes a feature is still undefined
    - issue management
    - the difference between an accepted design and a proposal
    - the organization of design proposals
    
    This proposal attempts to place these concerns within a general
    framework.
    
    
    See [TEP-1](https://github.com/tektoncd/community/blob/master/teps/0001-tekton-enhancement-proposal-process.md) for more details.
    

home, Nixos and the rest of thing

I did some big changes in my home repository, it’s still much a work-in-progress but it is in a way better state than before.

  • It is more reproductible. All dependencies are managed by niv and all machines are using a pinned version of channels from there. That way I can test the configuration (on the CI) and cache the packages for all channels that my machines uses. I also can decide when I want to upgrade a particular channel (nixos, unstable, …).
  • I am slowly experimenting on simplifying things more and more. This is a bit related to the previous post. I am trying to use Gnome3 everywhere. Well configured, managed by NixOS, it’s enough for my test and reduce the configuration cruft I need to do.

An ongoing work is my knowledge base and how it is published as part of this website : articles. I am trying to make all those publishable (for the one that do not hold any secret). I’ll document this a bit more at some point but…

  • Configurations are now part of that knowledge base, the docs folder of home is going away.
  • I am trying to use litterate configuration as much as possible. So slowly, the content from home will be a tangled version of my knowledge base. At least that is the goal as of today.

And I feel that’s all for June.