main
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
224bunch of small team — that have, for most of them, an actual product to deliver. The F2F
225showed that. AppStudio initial scope is relatively small and it could be handle way more
226efficiently by one <i>execution</i> team that design AppStudio based on it's need, and work on
227product (and with product teams) to achieve their goal. The amount of meetings and
228discussion added by this "cross-team" effort is enormous (and most likely tiring to a
229lot of folks, including me). And even like that, we have the feeling that there is not
230enough communication between teams (e.g., on what is the responsibilities and boundaries
231of each service — and assumption that we make). This also creates sources of contentions
232that would be not happening if AppStudio team was one <i>execution</i> team.</dd>
233
234<dt>Build Service / Tekton Service</dt><dd><p>
235For some reason, we brought OSBS and CPaaS team in the AppStudio loop. For some reason,
236we <i>sold</i> them that AppStudio would fit their bill. But if we look at the requirements of
237each, they are very different. AppStudio has the smallest amount of requirements and
238somehow should encapsulate all the others ? As said above, it seems to me that the
239current vision of AppStudio is very very close to a Digital Ocean Apps made by Red
240Hat. This, in my opinion, has nothing to do with a lot of requirement OSBS and other
241have. It doesn't even tie AppStudio to KCP.
242</p>
243
244<p>
245Siamak 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
246Service (Tekton API served by something — kcp is impl. detail here) and AppStudio, OSBS,
247CPaaS, RHODS, and whatever-comes-next, to build build on top. In a simple term, all
248those services (internal or external) would build on top of the Tekton API. Benifiting
249from each others at different possible levels (Tasks, …). This got "changed" again, for
250being confusing — which is getting me confused. What is wrong with all building on top
251of Tekton ? Do we feel Tekton abstraction is not at the right level ? Do we think the
252abstraction that will be at AppStudio Build Service level will be the right one and more
253importantly, will "fit them all" ? (note: if so, then why do we consider Tekton API in
254the picture at all, is one question we can ask ourselves). Most importantly what are the
255reason we <b>absolutely</b> want to use the exact same system for all ? If it's to be able to
256say "we use the same tools as what we are selling", isn't the tekton api (+ tasks, … )
257level, openshift, etc., good enough already ?
258</p>
259
260<p>
261Most of the time (to not say <b>all the time</b>), duplication is better than the wrong
262abstraction. I'd rather have a few things duplicated between OSBS, CPaaS, Appstudio, …
263to start with, gather information on what are those duplication, and do something about
264it, than trying to resolve all of the problems with one abstraction that has a high
265chance of not getting it right anyway.
266</p>
267
268<p>
269It also seems the experience and "service" vision, long-term (kcp, …), is disconnected
270from the first(s) milestone(s) of AppStudio. What do we want to achieve for Red Hat Summit
271and after ? Is our goal to present something that is usable by customer even if it
272doesn't do anything like the long-term vision (aka not based on kcp, …) ? Or is the goal
273to show that KCP vision applies and work. If it's the 2nd, then, AppStudio should not
274only go at the KCP vision pace but also actually participating to it, working towards it
275and not focus on providing an AppStudio experience independently of it. KCP seems to be
276at a relative experimental state, and, thus, if we consider AppStudio as a <i>capability</i> on
277top of KCP, AppStudio itself should be consider in an experimental state too (and
278organizationally wise it would change how we do things).
279</p></dd>
280
281<dt>Decision mechansims and "unilateral changes"</dt><dd><p>
282I have some relative concerns around how is AppStudio Build Service being discussed and
283who is talking about what, and when. Decision, and discussion should be taken with all
284representative as part of it (Siamak, Guillaume, …) and it feels like sometimes some
285decision 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
287sharing 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
289feedback"). This creates some confusion around who are the representative of the Build
290Service team, and the Pipeline team for example. From my point of view, anyone who is
291not part of the execution teams, is not a representative of those teams and it feels
292really weird to me that potential discussion and decision are taken by individuals that
293are not part of the "execution" (organizing the work, reviewing, committing to do
294something, …).
295</p>
296
297<p>
298From my perspective (and the team perspective), I would assume (and am assuming) that
299anything that is not shared to the rest of the team and not written somewhere (and
300accepted/agreed by the stakholder of the project) is not decided yet and can be
301discussed, changed or discarded.
302</p>
303
304<p>
305All of this causes frustration and not only for me, and it causes enough frustration for
306me to have to write this and get it out of my brain. I am of course available to discuss
307those 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>