<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, On 5/22/2024 12:04 PM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi, I think we need some clarification and facing reality on what can be done. </blockquote> Ok. I like your realistic approach. What I was suggesting (thanks Ken and Mariano for commiting your time to that) is more ambitious, difficult, and perhaps not needed. <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> Regarding a given Cuis stable release and a given package, being part of Cuis-Smalltalk organisation or not, I think about two different aspects of the package: 1. being compatible, known to work, with the given Cuis stable release 2. being maintained for this given Cuis stable release, its code will evolve within this branch, I guess this is what you call LTS I have absolutely zero resource to do #2, like maintaining LTS for Cuis-Smalltalk-UI for example . I have difficulty to find free time to work on DrGeo or Dynabook. </blockquote> We can try #1. That is, right after we freeze the stable release (that should be done in no more than a couple of weeks), we can review 3rd party packages, and after some testing and quality assessing, we can tag their current commit as "Cuis7.0Stable ready". Maybe that is enough. We don't have yet enough experience to know if more than that is needed. If we actually need to go #2, yes, we'll need to open branches on the affected repos. <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> Discussion continue below. <div class="moz-cite-prefix">Le 21/05/2024 à 15:25, Juan Vuletich a écrit : </div> <blockquote type="cite" cite="mid:664CA0CD.8010100@cuis.st"> But I think it is more important to find out which '3rd party' packages we want (and are able to!) support for a stable release. Stable releases are meant to be high quality, and users expect them to work for a long time. They are "LTS" releases (Long Term Support). We can only include packages we know are in good shape, and someone has committed to provide support for them as part of the stable release. We haven't been explicit about this before, basically because I'll be doing that for the packages in the Cuis7-0 repository. But I can't do that for packages I don't use and don't know too much about how they work. </blockquote> Sure you can't and you shouldn't do that. A maintainers of a package should decide if they want to inform about #1 and/or volunteer to #2 or none, in this later case package only evolve with -dev version. I have no idea how this should be done but a common rule, description how to do it will be useful to both maintainer and user of any given package for Cuis. I guess you wan to rely on git capability. </blockquote> Yep. <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> <blockquote type="cite" cite="mid:664CA0CD.8010100@cuis.st"> The next step needs to be to identify those packages. I know, (this is just an example), that GeographicInformationSystems is cool. But I haven't used it in quite some time. So unless someone else has, it doesn't qualify as "well maintained and routinely used". Obviously, if there is some project actually using it, the situation is completely different. So we need that list of packages to work on. </blockquote> Even if not used, such package could be tagged to be known to work, or may be just load ? </blockquote> Yes. But I'd devote at least one hour, after Cuis7.0Stable is out, to check that it loads, all tests pass, and example scripts do work. Then we can tag it. <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> <blockquote type="cite" cite="mid:664CA0CD.8010100@cuis.st"> I took a not-too-old DrGeo image I had on my machine, and looked at the packages it has loaded. Hilaire please correct me if this is wrong or incomplete. Some of these packages are already in the Cuis7-0 repo. Others are specific to DrGeo. I'm not listing any of them in what follows. Many packages are in other (3rd party) repos in the Cuis-Smalltalk organization. So, these are the repos / packages we need to work on: - Numerics / 'LinearAlgebra' - SVG / 'SVG' - Parsers / 'PetitParser' - Erudite / 'PetitParserBinding' 'Erudite' - Cuis-Smalltalk-UI / 'UI-Click-Select' 'UI-Core' 'UI-Entry' 'UI-Panel' 'UI-Preference' 'UI-Widgets' I'll support Numerics / 'LinearAlgebra' and SVG / 'SVG' under the repo structure we decide for "3rd party packages for Cuis Stable Releases". I think they are mature and stable, and haven't had issues in a long time. So, Hilaire and Ken, do you think that the Cuis-Smalltalk-UI packages are stable enough to be in a stable release with long term support? If needed, will you give support for them, not only for the current Rolling Release, but also for Stable Releases? These will be different package files, and most likely on separate repos. </blockquote> As I wrote I can't do #2 on these packages. </blockquote> It is OK. We'll find our way. <blockquote cite="mid:4a4185da-52b2-4947-ab00-d3ff00ddaddc@free.fr" type="cite"> <blockquote type="cite" cite="mid:664CA0CD.8010100@cuis.st"> I apologize for asking bluntly, but we need to be confident, before stamping "LongTermSupport'd" on any packages. </blockquote> I think an intermediate status as "known to work" with will be more realistic. Hilaire <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu.org/s/dr-geo/">http://gnu.org/s/dr-geo/</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu-drgeo.blogspot.com/">http://gnu-drgeo.blogspot.com/</a></pre> </blockquote> Yes. Thanks Hilaire for your honest and thoughtful answer. This discussion is really useful! Cheers, <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich</pre> </body> </html>