Here is my suggestion.
Primary goals:
* Stability
- because that's the stage in the project's life cycle
- if anyone wants to invest in development, that's fine too, but is
not what the current stewards of the project should be concentrating on
* Availability
- because stability for users (including admins) requires that they
can deploy it where they need it, and keep it up to date easily
- availability is currently poor -- see "Software Distribution" in
https://blog.foad.me.uk/2018/12/07/svn-whats-in-my-head/
For Stability:
* encourage commercial engagement for project maintenance
* encourage community maintenance by accepting minor feature
contributions and experimental initiatives
- don't let them compromise stability
* seek to remove or hide rough edges in existing features
- e.g. hide experimental features behind an opt-in config
For Availability:
* support availability of up-to-date install packages
- including today's cloud/container deployment platforms
* improve ease for downstream consumers using our releases
- see Mark's response about Subclipse
How?
* invite companies to contribute their existing build systems
- CollabNet, Assembla, RhodeCode, WANdisco
* find out what are the main desired target platforms
- provide a reference build system for each platform
- find and support maintainers for each platform
* change our release schedule to focus on maintenance releases
- reduce friction in version numbering, compatibility, multiple
release lines
* improve ease of producing new releases, especially bug fix releases
- automate the release steps (aim towards "one click")
- reduce friction in backports and releases policies (voting, etc.)
--
- Julian
