[GitHub] [accumulo] ctubbsii commented on pull request #3076: Call FSDataOutputStream.setDropBehind for WAL files

[GitBox <gi...@apache.org>]

ctubbsii commented on PR #3076:
URL: https://github.com/apache/accumulo/pull/3076#issuecomment-1314290954

   > IIRC in previous situations like this, you had suggested to people that changes should be made in the most recent version and then cherry-picked backwards.
   
   The circumstances differ here from that suggestion in a several important ways:
   
   1. Both 2.x and 1.x versions had releases, and the proposed change was only being considered for the earlier 1.x version without consideration of the newer 2.x versions,
   2. The code had already changed substantially in 2.x, which would have required a different design from the proposed 1.x change, meaning we couldn't just consider the change in 1.x; consideration of the change in 2.x may have informed design choices for the 1.x version (it would be bad if 1.x went one direction, and 2.x went a different direction, so we needed to consider 2.x in order to ensure the changes in 1.x were headed in the same direction),
   3. The proposed changes then were non-trivial, and were still being polished, and it would have been premature to apply to an older stable release without fully understanding its impact, and
   4. Depending on how things went after considering the changes in 2.x, we may have decided we didn't want to make the changes in 1.x
   
   In this case, however:
   
   1. there is no newer released version to consider,
   2. the code between the branches is still identical,
   3. the changes are trivial, and
   4. we know up-front that we want to apply the changes to the earlier branch
   
   Under circumstances like this, it's a matter of considering what is most efficient for tooling. If this were applied to the main branch, we'd cherry-pick the changes directly to the 2.1 branch, then merge forward back into the main branch, resulting in two identical commits in the history of the main branch. There's no reason to do that here, since the end result is the same. It's better under these circumstances to apply to the 2.1 branch and do one merge into the main branch, leaving only the one substantive commit and one trivial merge commit.


-- 
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: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org