| Call To Action: Secure the future maintenance of Xtext [message #1823619] |
Mon, 30 March 2020 11:46 |
|
Hello Xtext Community,
You might have observed that the number of people actively contributing to Xtext & Xtend has decreased over the recent years. People move on or shift focus. Of course this has implications: Fewer resources mean fewer new features, fewer bugfixes, and reduced community support. On the other hand, the outside world is turning faster: Four Eclipse releases a year, two Java releases, Gradle, Maven, etc. This means that the effort for maintenance and release engineering is increasing at the same time. Building four releases per year including a dozen milestones, adapting to changes in Eclipse Platform, JDT, keeping pace with new Gradle version, changes in new Java Versions etc - all these activities take their toll. Also with the changes in the team structure, fewer and fewer people have the knowledge about the internal workings and the implications of changes inside and outside of Xtext. In a nutshell: the future maintenance of Xtext is a risk.
As there are many people out there using Xtext in their tools and products, this risk has to be mitigated. We are thinking about what can be done to improve the situation. This basically boils down to two things. itemis AG provides a maintenance budget that can be extended by buying support contracts (contact us at xtext@itemis.de for more information or discuss the issue) and/or getting more people involved and contributing. In the past the development and maintenance of Xtext was always a one/two company thing and never a real community effort. So getting interested parties involved in the maintenance process is going to be challenging.
At EclipseCon in Ludwigsburg this year we talked to a number of interested parties about what we can do and came up with these ideas:
- Make the general maintenance tasks more transparent and document what needs to be done and what has to be done to be part of an Eclipse Release
- Have an open call (Hangout, ...) to discuss the roadmap, what needs to be done and who can do what on a regularly basis (4-6 weeks)
- More automation of tasks
- Avoid duplicate tasks (mid-term, repo merge)
- Minimize the risk of things breaking (get rid of old xpand generator/dependency, don't make extensive use of Xtend with its tight integration into JDT, ASM etc and also no longer encourage users to use Xtend for everything that Java can do as good or even better nowadays, Xtend is no longer the Java 17 of today)
- Think about which features are important and which one can be dropped to reduce the effort
- Think about the release cadence and being part of the Eclipse simultaneous release train.
- Find maintainers for subcomponents like Gradle support.
- Find a better chat-like communication platform than Gitter is atm
This is just a first idea. We invite you to bring in your own ideas into the discussion at https://github.com/eclipse/xtext/issues/1721
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
[Updated on: Mon, 30 March 2020 12:55] by Moderator Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02203 seconds
] 
Search
Help
Register
Login
Home
