Re: Problem "Stable" is not stable

[BB <adamnt42@xxxxxxxxx>]

Some thoughts, comments inline.

b

On 29/8/24 10:35 am, Stéphane Aulery wrote:
> Hello,
>
> Warning: this is a rather long message in which I try to understand 
> the real situation of Gambas, the means and aspirations of its 
> developers, and draw on my experience after 10 years of developing the 
> free software WIKINDX.
>
> -------------------------------------------------------------
>
> 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.
> 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.

> How many active developers are there and for which parts?
Somewhere between less than 12 and about 50 or so. You would need to 
scan the history from way back even before the move to git to find out.
> 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.

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.

> 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.)
> Is there a distinction between officially maintained components and 
> third-party components?
Very much so and in several different ways. Mainly the Farm.
> -------------------------------------------------------------
>
> 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.
> -------------------------------------------------------------
>
> 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).

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!"

> [1] https://trunkbaseddevelopment.com/
> [2] https://wikindx.sourceforge.io/web/trunk/contributing/coding/
>
> Regards,