sodonnel commented on PR #8217:
URL: https://github.com/apache/ozone/pull/8217#issuecomment-2778072930
> The introduction of locking is not re architecting but adding the
capability to serialize in an alternate scheme. Going with feature branch might
be too heavy handed for this.
@kerneltime Recall the addition of a much smaller change to introduce atomic
rewrite, where yourself and @errose28 insisted on doing the development on a
branch. That change was much smaller and less impactful than this one.
While I agree this change is "framework code" and will not be impactful to
existing logic, the followup tasks might be impactful and done in several PRs
if they result in large changes:
```
Next PR will include:
integration of locking framework to flow
locking for obs key operation, bucket operation, volume operation and
MPU cases
https://issues.apache.org/jira/browse/HDDS-12386 configuration for lock
bucket length and timeout
```
In general I don't agree with pushing development to a branch too quickly,
because It is a pain to get the branch merged as it requires a vote. However,
we do need consistency on the project and to decide on what requires a branch
and what does not. Especially if the goal is to always have "master shippable".
Perhaps the test is, if a PR can leave master in a state where it is not
shippable without another PR (eg half the code using the old locking and half
using new locking), then the feature should be on a branch, even if the branch
is only 3 or 4 commits before merging back to master.
Another question is whether such a branch should need a vote to merge? I'd
argue that a short lived branch with a handful of commits is a useful thing and
should not require a vote to merge - it encourages small PRs which are easier
to review and build up the feature in a more natural way. It would make using
branches for this sort of thing light weight and tool to be used rather than a
burden.
That all said, I am not involved in this area of work and I am not following
how involved or risky this change is overall.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
