I think the roadmap could benefit from a timeline regarding the support
period. Like Ubuntu or Oracle does with Java.
In that context angularjs is no more supported by upstream which is a
big problem for enterprise customers. That was one motivation of
addressing the angular 2 migration.
Perhaps it would be a good idea to start with 2.0 beta releases to get
that going, it might be quite some effort to finish so better start early.
As many git repos change from master to main this could be a good time
to have main for 2.0 and a 1.x branch for the angular js based guacamole.
Important changes could be backported to the 1.x branch as well.
Regarding future development a similar approach as with the angular
migration could be discussed for a move towards Spring Boot: having a
backend library and a spring boot wrapper project that produces
artifacts that can be run directly or deployed to tomcat if desired.
That would make starting to use and develop guacamole much easier.
Best regards,
Thomas
On 2024/02/22 08:44:18 Michael Jumper wrote:
(This is particularly relevant to the Angular and X.Org changes.)
We have a ton of changes in flight of all sizes, both from Guacamole
committers and from contributors. The larger changes tend to get stuck
because ... they're large. The smaller changes tend to get stuck because
of basic issues with style which, while important, also serve as a
roadblock that makes things difficult for contributors and reviewers
alike (there's lots of back-and-forth, and lack of time leads to PRs
eventually getting ignored/forgotten).
I think we should adopt some changes to our branching and code review
methods to allow things to move forward more efficiently and without
risking breaking mainline.
To be clear, I'm not proposing that we alter the scope of review.
Instead, I think we should make it significantly easier for contributors
to abide by the style guidelines by providing some sort of script within
the guacamole-client and guacamole-server source that allows
contributors to automatically check/correct their own changes. Review on
our side can then be streamlined to just:
1) Verifying that script reports everything is clean.
2) Verifying the pure technical merit of the proposed changes.
With respect to avoiding changes getting stuck due to sheer size, I
propose we adopt a different branching strategy that builds off the
patch release procedures we recently adopted. Instead of a single
"master" branch, I suggest a set of 3 primary development branches:
(1) "patch" - Receives any changes that are bugfixes or minor
improvements that do not affect documentation. This is essentially
equivalent to what we've been doing with the staging branches for patch
releases, except that there would no longer be any need to create those
staging branches until the release process is actually underway. The
base branch for any changes that qualify would always consistently and
simply be "patch".
(2) "main" - Replaces current "master", receives all changes that are
not huge changes that would warrant a full major version bump. Changes
merged to "patch" get manually merged back to "main".
(3) "next" - Receives any changes that are so huge that they would
warrant a full major version bump. Changes merged to "main" get manually
merged to "next". In some cases, changes made against "main" may need to
be reimplemented against "next".
Now on to the...
----- PROPOSED ROADMAP -----
1.5.5:
* Remaining items already listed in JIRA
* Any bugfixes that have already been merged to master but are missing
from previous patch releases
1.5.6+:
* Any issues identified in 1.5.5
* Any changes related to automated style checks
* Duo v4 (if possible)
* Basic improvements/fixes for known issues with the terminal emulator
1.6.0:
* Remaining items already listed in JIRA
* The (experimental) X.org driver
* Finalize the migration to guacamole-common-js' improved event system
* Add remaining events for guacamole-ext's improved event system
* Generalize the Docker image to no longer require manually mapping
variables to properties (to avoid any future issues with unmapped or
incorrectly mapped properties)
* Support FreeRDP 3.0
* Improvements to the speed and efficiency guac_common_surface (and
moving the surface to libguac) <- I have an automatic scroll detection
algorithm that seems to work pretty well
1.7.0+:
* Support for WebAuthn
* Ability to automatically apply/update the database schema.
2.0.0:
* The AngularJS -> Angular migration.
* Migrate from javax.* to jakarta.*, thus supporting Tomcat 10 while
dropping support for Tomcat 9 and older.
* Backward-compatible, binary variation of Guacamole protocol (assuming
browsers are now capable of handling this efficiently, I have a rough
sketch of how this might look and how it might improve on the processing
required)
2.1.0+:
* Improve admin UX regarding management of objects (relegate some
parameters to an "advanced" tab/view, add tooltips and links to help).
* Load balancing / HA support for the webapp itself
Thoughts?
- Mike
--
Thomas Kruse
Beratung/Entwicklung
trion development GmbH
Heideggerstrasse 4, 48165 Muenster, Germany
https://www.trion.de/
Steuernummer: 336/5752/1454
USt-IdNr.: DE281970971
Sitz der Gesellschaft: Muenster
Registergericht: Amtsgericht Muenster, HR B 13716
Geschaeftsfuehrer: Thomas Kruse
