Hi Branko, > May I ask why you thought it's OK to ignore my request to implement this > major new FS feature on a branch and committed directly to trunk instead? > Clearly your change was incomplete, judging by the following several > commits. This is despite the fact that I plainly told you that this > community decided a while ago not to develop untested new features on trunk. > Stefan^2 even created the feature branch for you.
As I see it, this was a suggestion, not a request, and I did not ignore it. However, the patch received proper attention, we did resolve the technical issues with it, so I thought there is nothing wrong with committing it. It looks like we have another misunderstanding here with the "major FS feature" part. From my point of view, this is a *fix* for an existing FSFS feature (ability to share data and cache filesystem data), which does not work under certain circumstances. What I mean is, if this is a "major FS feature", what would a "minor" feature look like? And what would be a good example of a major FS feature with the same size, impact and importance for an end user, that went through the branch and voting procedure? > Now I'm going to ask you nicely to recreate that branch from current trunk > and revert this commit and all further related commits from trunk; I believe > that the full list is: > > 1618138; 1618151; 1618177 > > but don't take my word for it. Then, when you're sure the feature is ready, > ask for a vote to get the branch merged to trunk. > > Thanks, > > -- Brane If you insist, I will revert these changes from trunk and will attempt to commit them as a major FS feature with branching and voting. However, I do not really see any technical reason to do that. This is not a destabilizing change, and it solves a well-known problem that even we keep stumbling upon during the development process. Regards, Evgeny Kotkov
