Yes, the statements I made are a bit exaggerated. That was to bring out a little more discussion on balance of maintenance vs enhancement.
In my case, I am suggesting fixes because I have groovy-eclipse setup and this gives me a chance to make some small patches to groovy-core and see if they fix the problems I run into. For me to submit a PR to groovy-core, I would need to get that entire project setup and get familiarized with the build and test cycle. And then how would I decide how much time to spend trying to improve groovy-eclipse vs. groovy-core. I felt that reporting issues and submitting diffs/patches would be sufficient. Here are my top 3 from my bugs list: GROOVY-8509 error for call to protected method from same package GROOVY-8063 Type annotation value referencing inner class is not properly scoped GROOVY-7975 Use of static final field in an annotation element causes compile errors -----Original Message----- From: Jochen Theodorou [mailto:[email protected]] Sent: Wednesday, April 04, 2018 7:37 PM To: [email protected] Subject: Re: GROOVY-8527: Enhance import aliasing to an alias with a package name On 04.04.2018 21:38, [email protected] wrote: >>> [...]I have submitted over 20 bugs in the past months for existing >>> features that do not mix well with eachother or are not completely >>> implemented and yet I feel the core development thrust is not in >>> fixing bugs for existing features but in adding new features for the >>> sake of new features. >> >> not many are eager to spend their spare time after working hours on fixing >> complicated bugs and going through the whole process and discussions. > > If the incentive for fixing bugs was enticing enough, wouldn't there be eager > developers? Do you have a recipe of how to give an enticing incentive? Actually, from looking at your issues you are suggesting solutions in some places, but you seem not be motivated enough to make a pull request for example. Why is that? > What then is the point of adding new features onto an unhealthy, > under-supported language? I think you exaggerate. But the point is attracting new people. If you do not move, people move away. Annoying, long standing bugs can have the same effect of course > If this is truly the state of the union, then I would vote NO on all new > feature development. We need to find the right balance. The new parser for example does not exist because we wanted a new parser. It exists because the old parser started to become a problem for fixing bugs. Of course once you have a new parser, that is more maintainable and a person that understands it very well, you will also see features from other languages and see them with the eyes of a parser guy that is wondering if this brings any benefit to Groovy. That is natural. Anyway... the static compiler is a deep resource of bugs and will stay being it a long time. Inner classes in all variants contain new surprises time over time. But excluding those two topics what are your top 3 of open bugs in jira entered by you where existing features do not mix well with eachother or are not completely implemented? bye Jochen
