Re: Problem "Stable" is not stable

[Stéphane AULERY <lkppo@xxxxxxx>]

Le 29/08/2024 à 08:06, BB a écrit :
> On 29/8/24 10:35 am, Stéphane Aulery wrote:
> > The whole of Gambas is developed frontally. In my opinion the best is 
> > to divide and conquer and do dogfooding (this last thing is already 
> > applied by Benoît).
> The Gambas model is the "benevolent dictatorship". Which I believe 
> suits most of the long term users fine.

You're talking to me about the governance model when I'm talking about 
the release model. The first does not imply the second.


> > Divide Gambas into three or four layers based on importance, 
> > dependencies between components and automatic testability, and apply 
> > adapted release cycles from longest to shortest. This means that 
> > apart from fixes, you have to develop from the bottom up by applying 
> > a roadmap and/or separate development between teams.
> >
> > - The core / language (interpreter, compiler, archiver, and 
> > scripter): with a real release strategy where minor versions are 
> > published for the sole purpose of fixing, only one major version. 
> > With a small team it is unrealistic to maintain more than one version 
> > in the long term in addition to the trunk.
> > - A library of standard components, included with the core/language, 
> > the most important and testable written for a major version of the 
> > core (probably those that Benoît uses for his work).
> > - The IDE and the components that are essential to him : own version 
> > and release cycle, target previous parts.
> > - The other components: each has its own version and release cycle.
> >
> > -------------------------------------------------------------
> >
> > Is there a roadmap?
>
> No, no can there be really. Factors in influence here include forces 
> from outside the project, changes to the external libraries, GUIs etc. 
> Also Gambas is a toolkit not an end product in itself. That makes 
> concocting a feature based development calendar less sensible.
>
> Notwithstanding that, Benoit has always carefully advertised "large" 
> changes but they have not been calendarised unless they weree going to 
> change the engine in a major way, such as the Gambas 2 to 3 migration.

I don't see how the desired maturity for a toolkit or a compiler is not 
compatible with a roadmap.

Roadmap does not necessarily mean feature list. In this list, supporting 
GTK 3 or Qt6 is as valid as developing new component Foo, or fixing bug 
#154644.

If there is no roadmap there is no visibility outside of direct 
communication (mailing list only?).



> > Is there at least one developer and testers interested in release 
> > management instead of writing features?
>
> (Opinion) I doubt it. Given that it is a toolkit, most users are more 
> interested in their own products that are developed using Gambas 
> rather than Gambas development itself. In my experience it is only 
> when I needed Gambas to be "adjusted" slightly to suit my needs that I 
> got involved in changing Gambas itself.

It exists. I'm interested in it and that's exactly what I do for 
WIKINDX. I focus mainly on maintenance and releases, and I leave it to 
the other developer to develop the business features where he is a 
specialist.

Whether I have the skills for this in C, Qt, ... is another thing.


> Also, some of the contributors also run their own modified versions of 
> Gambas to suit their own ends. Some of those mods do make it back into 
> the core on occasion. I can think of no general reason for this. No do 
> I think it is a good or a bad thing but it does make you roadmap idea 
> less likely.
I suggested breaking the project into layers so those writing components 
can follow their own agenda.



> > Is there a dependency system between the language version and the 
> > components, and for the components between them?
> I dont really understand what you are saying here. I think so but I 
> don't see it as an issue. The components, once included, go on forever 
> with Benoit making sure that backward compatibility is maintained 
> (except in the obvious cases where it cant be.)
Maintaining all these components cannot rely on a single person. Benoît 
says this in his email. Even if he adapts the code of all components, he 
does not test them all. Contributors can't just spawn components and 
disappear hoping that the benevolent dictator is actually their slave 
and insurance.

On this page https://gambaswiki.org/wiki/comp, Gambas version is the 
first apparition of the component or the compatibility version with the 
core ?
Some doc page have component X requires component Y, but no version of 
Gambas, no name and version of the library behind.
If developing the whole thing at the same time is sustainable, that's 
not a big problem, obviously.


> > Is there a distinction between officially maintained components and 
> > third-party components?
> Very much so and in several different ways. Mainly the Farm.

I don't know what the Farm is.


> > -------------------------------------------------------------
> >
> > That said, with very few developers, the best thing is perhaps to 
> > divide in two: what is essential to the language, the rest of the 
> > components and software.
> >
> > What is essential following a long cycle with an X.Y.Z scheme and the 
> > rest a rapid development based on the trunk and an 
> > X-YYYMMJJ-.build_number scheme which openly shows the less stable part.
> >
> > Maybe the site trunkbaseddevelopment.com [1] can help you organize 
> > releases with a small development team.
> >
> > 5 days of testing is an eternity for a solo professional developer 
> > but for a hobbyist or a team it is far from enough. 1 week seems the 
> > bare minimum in my opinion and even rather 2 weeks.
> (Strong opinion) As a retired test consultant I can only say that time 
> based testing is a ridiculous idea.

I am not advocating for time-based testing. I am saying that there 
should be a minimum amount of time to allow for the opportunity to 
actually test and coordinate.

There must also be times when developers STOP writing code, and test 
thoroughly, instead of having fun adding or changing until the last minute.


> > -------------------------------------------------------------
> >
> > For WIKINDX, a software that I develop in pairs, I only maintain one 
> > major version in addition to the development version. To publish it I 
> > apply a RC (Release Candidate) system like the development of the 
> > Linux kernel [2]. We alternate between developing features following 
> > a roadmap and RCs to test in depth, and debug the final version. We 
> > chose this approach after a long observation time because:
> > - We are only 2 developers
> > - We only have one non-developer tester
> > - Over time we have gauged that we do not have the capacity to 
> > release more than two major versions by year. If we try to go faster 
> > we introduce more bugs than we fix.
> > - With a roadmap we can focus on the most important things, choose 
> > our effort, balance between adding features, polishing, testing, 
> > maintenance, better coordinate with other people.
> >
> > I think that the solution chosen must be adopted according to the 
> > real capacities of the team, the nature of the software and its use, 
> > the users and external contributions.
>
> Cant say that I disagree with you there. Then again, I don't really 
> see a "problem" with how things are done now. Christof's original post 
> was about nomenclature not really about changing how things are done 
> (IMO).

For me it is a lack of not finding in the FAQ a point that explains at 
least the release cycle and how to read the version number. I have the 
feeling that the strategy is what happens when it happens and who loves 
me follows me. It is not a strategy.


> I have been (in the past) a member of 2 software communes that used 
> Gambas to develop purpose built systems. In both those cases we used a 
> development/release approach very much like that which you have 
> outlined, but they were systems with specific end purposes, not 
> toolkits.  Going back to the OP, yes we had similar situations to that 
> expressed by Laurux and our solution was exactly the same..."Don't 
> update your Gambas until we tell you to!"
If Laurux explicitly documented its compatibility with Gamabs versions 
there would be no need to send stimuli.

--
Stéphane Aulery