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
Received on 2014-08-17 01:54:25 CEST