<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 11 juin 2022, 03 h 30, Brad Hards via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, 11 June 2022 12:58:58 PM AEST Nicolas Dufresne via gstreamer-<br>
devel wrote:<br>
> Somehow though your team will have to read the documentation to translate<br>
> this good, bad and the ugly joke into what this is really is.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Please read through all the discussion that lead us to this compromise into getting monorepo. All this have happen in the public space. From there you could lead a second round of disturbing changes discussions. I believe though that after 4 years of majors disruptive changes we wanted to make a pause and gives the distributors a bit of breathing. A short summary of major changes:</div><div dir="auto"><br></div><div dir="auto">- autotools -> meson</div><div dir="auto">- anongit -> gitlab</div><div dir="auto">- buildroot CI -> gitlab CI</div><div dir="auto">- monorepo</div><div dir="auto"><br></div><div dir="auto">When we did monorepo, we did not change the tarballs, meaning we kept the original tarballs, base, good, bad, ugly and more. That implied stepping back from removing internal subproject and limits the ability to rename and move directories.</div><div dir="auto"><br></div><div dir="auto">Breaking Linux distributions packaging requires a lot of planning, and time to assist the packagers, and to reassure those that have a challenging time with source code implement patents. In short, we discussed this already, and are well aware of all the other improvements we could make with removing the subproject. Notably, we could make use of unstable API in stable plugins.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Perhaps its time to evolve the plugin directory structure? Now we have the <br>
mono repo, there could be a more nuanced approach.<br>
<br>
In particular, "bad" isn't all the same-kind-of-bad.<br>
<br>
Some of it is "the code is mostly pretty good, but the API is not forever-<br>
level stable".<br>
"bad" -> "unstable"<br>
<br>
Some of it is "its not all done yet" - more WIP, although useful the way it <br>
is.<br>
"bad" -> "staging" or "testing" (or "community contribution" or something like <br>
that).<br>
<br>
Some of it is "well, maybe that wasn't the greatest idea after all"<br>
"bad" -> "bad" :-)<br>
<br>
I'm sure there are more aspects that I'm missing.<br>
<br>
Having some intermediate stages might be easier than "all the way from good in <br>
a single step".<br>
<br>
Not sure if any of that is going to help with the "MRs take forever to get <br>
reviewed" problem though...<br>
<br>
Brad<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div>