www

My personal website(s)
Log | Files | Refs

2021-10.private.html (14628B)


      1 <?xml version="1.0" encoding="utf-8"?>
      2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
      4 <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
      5 <head>
      6 <!-- 2021-10-19 Tue 14:36 -->
      7 <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
      8 <meta name="viewport" content="width=device-width, initial-scale=1" />
      9 <title>2021-10 Journal</title>
     10 <meta name="generator" content="Org mode" />
     11 <meta name="author" content="Vincent Demeester" />
     12 <style type="text/css">
     13  <!--/*--><![CDATA[/*><!--*/
     14   .title  { text-align: center;
     15              margin-bottom: .2em; }
     16   .subtitle { text-align: center;
     17               font-size: medium;
     18               font-weight: bold;
     19               margin-top:0; }
     20   .todo   { font-family: monospace; color: red; }
     21   .done   { font-family: monospace; color: green; }
     22   .priority { font-family: monospace; color: orange; }
     23   .tag    { background-color: #eee; font-family: monospace;
     24             padding: 2px; font-size: 80%; font-weight: normal; }
     25   .timestamp { color: #bebebe; }
     26   .timestamp-kwd { color: #5f9ea0; }
     27   .org-right  { margin-left: auto; margin-right: 0px;  text-align: right; }
     28   .org-left   { margin-left: 0px;  margin-right: auto; text-align: left; }
     29   .org-center { margin-left: auto; margin-right: auto; text-align: center; }
     30   .underline { text-decoration: underline; }
     31   #postamble p, #preamble p { font-size: 90%; margin: .2em; }
     32   p.verse { margin-left: 3%; }
     33   pre {
     34     border: 1px solid #ccc;
     35     box-shadow: 3px 3px 3px #eee;
     36     padding: 8pt;
     37     font-family: monospace;
     38     overflow: auto;
     39     margin: 1.2em;
     40   }
     41   pre.src {
     42     position: relative;
     43     overflow: auto;
     44     padding-top: 1.2em;
     45   }
     46   pre.src:before {
     47     display: none;
     48     position: absolute;
     49     background-color: white;
     50     top: -10px;
     51     right: 10px;
     52     padding: 3px;
     53     border: 1px solid black;
     54   }
     55   pre.src:hover:before { display: inline; margin-top: 14px;}
     56   /* Languages per Org manual */
     57   pre.src-asymptote:before { content: 'Asymptote'; }
     58   pre.src-awk:before { content: 'Awk'; }
     59   pre.src-C:before { content: 'C'; }
     60   /* pre.src-C++ doesn't work in CSS */
     61   pre.src-clojure:before { content: 'Clojure'; }
     62   pre.src-css:before { content: 'CSS'; }
     63   pre.src-D:before { content: 'D'; }
     64   pre.src-ditaa:before { content: 'ditaa'; }
     65   pre.src-dot:before { content: 'Graphviz'; }
     66   pre.src-calc:before { content: 'Emacs Calc'; }
     67   pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
     68   pre.src-fortran:before { content: 'Fortran'; }
     69   pre.src-gnuplot:before { content: 'gnuplot'; }
     70   pre.src-haskell:before { content: 'Haskell'; }
     71   pre.src-hledger:before { content: 'hledger'; }
     72   pre.src-java:before { content: 'Java'; }
     73   pre.src-js:before { content: 'Javascript'; }
     74   pre.src-latex:before { content: 'LaTeX'; }
     75   pre.src-ledger:before { content: 'Ledger'; }
     76   pre.src-lisp:before { content: 'Lisp'; }
     77   pre.src-lilypond:before { content: 'Lilypond'; }
     78   pre.src-lua:before { content: 'Lua'; }
     79   pre.src-matlab:before { content: 'MATLAB'; }
     80   pre.src-mscgen:before { content: 'Mscgen'; }
     81   pre.src-ocaml:before { content: 'Objective Caml'; }
     82   pre.src-octave:before { content: 'Octave'; }
     83   pre.src-org:before { content: 'Org mode'; }
     84   pre.src-oz:before { content: 'OZ'; }
     85   pre.src-plantuml:before { content: 'Plantuml'; }
     86   pre.src-processing:before { content: 'Processing.js'; }
     87   pre.src-python:before { content: 'Python'; }
     88   pre.src-R:before { content: 'R'; }
     89   pre.src-ruby:before { content: 'Ruby'; }
     90   pre.src-sass:before { content: 'Sass'; }
     91   pre.src-scheme:before { content: 'Scheme'; }
     92   pre.src-screen:before { content: 'Gnu Screen'; }
     93   pre.src-sed:before { content: 'Sed'; }
     94   pre.src-sh:before { content: 'shell'; }
     95   pre.src-sql:before { content: 'SQL'; }
     96   pre.src-sqlite:before { content: 'SQLite'; }
     97   /* additional languages in org.el's org-babel-load-languages alist */
     98   pre.src-forth:before { content: 'Forth'; }
     99   pre.src-io:before { content: 'IO'; }
    100   pre.src-J:before { content: 'J'; }
    101   pre.src-makefile:before { content: 'Makefile'; }
    102   pre.src-maxima:before { content: 'Maxima'; }
    103   pre.src-perl:before { content: 'Perl'; }
    104   pre.src-picolisp:before { content: 'Pico Lisp'; }
    105   pre.src-scala:before { content: 'Scala'; }
    106   pre.src-shell:before { content: 'Shell Script'; }
    107   pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
    108   /* additional language identifiers per "defun org-babel-execute"
    109        in ob-*.el */
    110   pre.src-cpp:before  { content: 'C++'; }
    111   pre.src-abc:before  { content: 'ABC'; }
    112   pre.src-coq:before  { content: 'Coq'; }
    113   pre.src-groovy:before  { content: 'Groovy'; }
    114   /* additional language identifiers from org-babel-shell-names in
    115      ob-shell.el: ob-shell is the only babel language using a lambda to put
    116      the execution function name together. */
    117   pre.src-bash:before  { content: 'bash'; }
    118   pre.src-csh:before  { content: 'csh'; }
    119   pre.src-ash:before  { content: 'ash'; }
    120   pre.src-dash:before  { content: 'dash'; }
    121   pre.src-ksh:before  { content: 'ksh'; }
    122   pre.src-mksh:before  { content: 'mksh'; }
    123   pre.src-posh:before  { content: 'posh'; }
    124   /* Additional Emacs modes also supported by the LaTeX listings package */
    125   pre.src-ada:before { content: 'Ada'; }
    126   pre.src-asm:before { content: 'Assembler'; }
    127   pre.src-caml:before { content: 'Caml'; }
    128   pre.src-delphi:before { content: 'Delphi'; }
    129   pre.src-html:before { content: 'HTML'; }
    130   pre.src-idl:before { content: 'IDL'; }
    131   pre.src-mercury:before { content: 'Mercury'; }
    132   pre.src-metapost:before { content: 'MetaPost'; }
    133   pre.src-modula-2:before { content: 'Modula-2'; }
    134   pre.src-pascal:before { content: 'Pascal'; }
    135   pre.src-ps:before { content: 'PostScript'; }
    136   pre.src-prolog:before { content: 'Prolog'; }
    137   pre.src-simula:before { content: 'Simula'; }
    138   pre.src-tcl:before { content: 'tcl'; }
    139   pre.src-tex:before { content: 'TeX'; }
    140   pre.src-plain-tex:before { content: 'Plain TeX'; }
    141   pre.src-verilog:before { content: 'Verilog'; }
    142   pre.src-vhdl:before { content: 'VHDL'; }
    143   pre.src-xml:before { content: 'XML'; }
    144   pre.src-nxml:before { content: 'XML'; }
    145   /* add a generic configuration mode; LaTeX export needs an additional
    146      (add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
    147   pre.src-conf:before { content: 'Configuration File'; }
    148 
    149   table { border-collapse:collapse; }
    150   caption.t-above { caption-side: top; }
    151   caption.t-bottom { caption-side: bottom; }
    152   td, th { vertical-align:top;  }
    153   th.org-right  { text-align: center;  }
    154   th.org-left   { text-align: center;   }
    155   th.org-center { text-align: center; }
    156   td.org-right  { text-align: right;  }
    157   td.org-left   { text-align: left;   }
    158   td.org-center { text-align: center; }
    159   dt { font-weight: bold; }
    160   .footpara { display: inline; }
    161   .footdef  { margin-bottom: 1em; }
    162   .figure { padding: 1em; }
    163   .figure p { text-align: center; }
    164   .equation-container {
    165     display: table;
    166     text-align: center;
    167     width: 100%;
    168   }
    169   .equation {
    170     vertical-align: middle;
    171   }
    172   .equation-label {
    173     display: table-cell;
    174     text-align: right;
    175     vertical-align: middle;
    176   }
    177   .inlinetask {
    178     padding: 10px;
    179     border: 2px solid gray;
    180     margin: 10px;
    181     background: #ffffcc;
    182   }
    183   #org-div-home-and-up
    184    { text-align: right; font-size: 70%; white-space: nowrap; }
    185   textarea { overflow-x: auto; }
    186   .linenr { font-size: smaller }
    187   .code-highlighted { background-color: #ffff00; }
    188   .org-info-js_info-navigation { border-style: none; }
    189   #org-info-js_console-label
    190     { font-size: 10px; font-weight: bold; white-space: nowrap; }
    191   .org-info-js_search-highlight
    192     { background-color: #ffff00; color: #000000; font-weight: bold; }
    193   .org-svg { width: 90%; }
    194   /*]]>*/-->
    195 </style>
    196 <script type="text/javascript">
    197 // @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
    198 <!--/*--><![CDATA[/*><!--*/
    199      function CodeHighlightOn(elem, id)
    200      {
    201        var target = document.getElementById(id);
    202        if(null != target) {
    203          elem.classList.add("code-highlighted");
    204          target.classList.add("code-highlighted");
    205        }
    206      }
    207      function CodeHighlightOff(elem, id)
    208      {
    209        var target = document.getElementById(id);
    210        if(null != target) {
    211          elem.classList.remove("code-highlighted");
    212          target.classList.remove("code-highlighted");
    213        }
    214      }
    215     /*]]>*///-->
    216 // @license-end
    217 </script>
    218 </head>
    219 <body>
    220 <div id="content">
    221 <h1 class="title">2021-10 Journal</h1>
    222 <dl class="org-dl">
    223 <dt>AppStudio organization across teams</dt><dd>The way AppStudio is organize is relatively to <b>very</b> inefficient. Trying to organize a
    224 bunch of small team — that have, for most of them, an actual product to deliver. The F2F
    225 showed that. AppStudio initial scope is relatively small and it could be handle way more
    226 efficiently by one <i>execution</i> team that design AppStudio based on it's need, and work on
    227 product (and with product teams) to achieve their goal.  The amount of meetings and
    228 discussion added by this "cross-team" effort is enormous (and most likely tiring to a
    229 lot of folks, including me). And even like that, we have the feeling that there is not
    230 enough communication between teams (e.g., on what is the responsibilities and boundaries
    231 of each service — and assumption that we make). This also creates sources of contentions
    232 that would be not happening if AppStudio team was one <i>execution</i> team.</dd>
    233 
    234 <dt>Build Service / Tekton Service</dt><dd><p>
    235 For some reason, we brought OSBS and CPaaS team in the AppStudio loop. For some reason,
    236 we <i>sold</i> them that AppStudio would fit their bill. But if we look at the requirements of
    237 each, they are very different. AppStudio has the smallest amount of requirements and
    238 somehow should encapsulate all the others ? As said above, it seems to me that the
    239 current vision of AppStudio is very very close to a Digital Ocean Apps made by Red
    240 Hat. This, in my opinion, has nothing to do with a lot of requirement OSBS and other
    241 have. It doesn't even tie AppStudio to KCP.
    242 </p>
    243 
    244 <p>
    245 Siamak tried to clarify a bit this in <a href="https://docs.google.com/presentation/d/1Y4555ByKNnc-IqudjpimeHCwO-q8XPMpYkbGVk9glmk/edit#slide=id.gf4c3d0aa3b_0_17">Managed Tekton Service</a>, by proposing a Tekton
    246 Service (Tekton API served by something — kcp is impl. detail here) and AppStudio, OSBS,
    247 CPaaS, RHODS, and whatever-comes-next, to build build on top. In a simple term, all
    248 those services (internal or external) would build on top of the Tekton API. Benifiting
    249 from each others at different possible levels (Tasks, …). This got "changed" again, for
    250 being confusing — which is getting me confused. What is wrong with all building on top
    251 of Tekton ? Do we feel Tekton abstraction is not at the right level ? Do we think the
    252 abstraction that will be at AppStudio Build Service level will be the right one and more
    253 importantly, will "fit them all" ? (note: if so, then why do we consider Tekton API in
    254 the picture at all, is one question we can ask ourselves). Most importantly what are the
    255 reason we <b>absolutely</b> want to use the exact same system for all ? If it's to be able to
    256 say "we use the same tools as what we are selling", isn't the tekton api (+ tasks, … )
    257 level, openshift, etc.,  good enough already ?
    258 </p>
    259 
    260 <p>
    261 Most of the time (to not say <b>all the time</b>), duplication is better than the wrong
    262 abstraction. I'd rather have a few things duplicated between OSBS, CPaaS, Appstudio, …
    263 to start with, gather information on what are those duplication, and do something about
    264 it, than trying to resolve all of the problems with one abstraction that has a high
    265 chance of not getting it right anyway.
    266 </p>
    267 
    268 <p>
    269 It also seems the experience and "service" vision, long-term (kcp, …), is disconnected
    270 from the first(s) milestone(s) of AppStudio. What do we want to achieve for Red Hat Summit
    271 and after ? Is our goal to present something that is usable by customer even if it
    272 doesn't do anything like the long-term vision (aka not based on kcp, …) ? Or is the goal
    273 to show that KCP vision applies and work. If it's the 2nd, then, AppStudio should not
    274 only go at the KCP vision pace but also actually participating to it, working towards it
    275 and not focus on providing an AppStudio experience independently of it. KCP seems to be
    276 at a relative experimental state, and, thus, if we consider AppStudio as a <i>capability</i> on
    277 top of KCP, AppStudio itself should be consider in an experimental state too (and
    278 organizationally wise it would change how we do things).
    279 </p></dd>
    280 
    281 <dt>Decision mechansims and "unilateral changes"</dt><dd><p>
    282 I have some relative concerns around how is AppStudio Build Service being discussed and
    283 who is talking about what, and when. Decision, and discussion should be taken with all
    284 representative as part of it (Siamak, Guillaume, …) and it feels like sometimes some
    285 decision or changes are don unilaterally. A good example of this is the recent changes
    286 <a href="https://docs.google.com/presentation/d/1Y4555ByKNnc-IqudjpimeHCwO-q8XPMpYkbGVk9glmk/edit#slide=id.gf4c3d0aa3b_0_17">Managed Tekton Service</a> slidedeck, without any prior discussion, and without actually
    287 sharing with the rest of the stakeholders what is confusing about the current setup
    288 (note that it had been shared with all the folks and we didn't have that "it's confusing
    289 feedback"). This creates some confusion around who are the representative of the Build
    290 Service team, and the Pipeline team for example. From my point of view, anyone who is
    291 not part of the execution teams, is not a representative of those teams and it feels
    292 really weird to me that potential discussion and decision are taken by individuals that
    293 are not part of the "execution" (organizing the work, reviewing, committing to do
    294 something, …).
    295 </p>
    296 
    297 <p>
    298 From my perspective (and the team perspective), I would assume (and am assuming) that
    299 anything that is not shared to the rest of the team and not written somewhere (and
    300 accepted/agreed by the stakholder of the project) is not decided yet and can be
    301 discussed, changed or discarded.
    302 </p>
    303 
    304 <p>
    305 All of this causes frustration and not only for me, and it causes enough frustration for
    306 me to have to write this and get it out of my brain. I am of course available to discuss
    307 those thoughts more, either by mail or on a call with you all.
    308 </p></dd>
    309 </dl>
    310 </div>
    311 <div id="postamble" class="status">
    312 <p class="author">Author: Vincent Demeester</p>
    313 <p class="date">Created: 2021-10-19 Tue 14:36</p>
    314 <p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
    315 </div>
    316 </body>
    317 </html>