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