On Friday 24 January 2014 16:09:11 Gennadiy Rozental wrote:
Andrey Semashev
writes: If you fixed a bug in trunk but didn't find a chance to merge the fix to release for years then you clearly don't have the resources to properly maintain the library. "It's been fixed in trunk" is not an excuse.
I think you not exactly appreciate amount of time/effort it require to push the change in core library to release branch.
I think I have the idea.
Regardless of number of maintainers, this is still has a significant probability of being disruptive and I decided not pursue it unlesss I have a lot of time time to address the issues and really good reason to back up the change.
I can understand that you're trying to be careful about changes and I can only welcome that. But there is difference between being careful and stagnating, and the latter seems to be what's happening.
The best policy is to push changes in batches, but now Iam stuck, since I can't push latest changes till I document them.
I think it is best to push changes in small chunks (maybe, each feature separately) but often. This allows people to adapt gradually and simplifies tracking down possible problems. This is also true for documentation, although it's not that critical. Otherwise you have the situation like this - when you have to merge a lot of changes at once and the probability of breaking something is high.