-0
While I really appreciate the great work, and I would like to have this
branch merged, I didn't feel that I got the answer to my previous
question (which commit is the merge candidate?, is HDDS-5118 a release
blocker issue?)
It turns out that I have different opinion about "let's finish it on the
master".
https://twitter.com/anzix/status/1385511955943854084
I am against to merge security issues, licensing issues and build time
issues to the master. Or any issue which can cause crashes or data
corruption.
In other words: keeping any release blocked any master with the hope
that they will be fixed soon.
My rule is simple: would I vote a release with such issues?
I understand that in this case there are only small issue and they can
be fixed very fast, therefore I couldn't see any reason to not fixing
them BEFORE the merge (and I would be happy to help to fix them)
Last time we had one simple release blocker issue merged on the master
(we used -SNAPSHOT dependency required by the more agile development)
and the release was delayed with 3-4 months (!!!)
Personally I suggest to follow a practice when master is always releasable.
* If issues can be fixed easily, they should be fixed before merging
the master.
* If issues require significant work they shouldn't be merged.
Just to be clear: I am not talking about missing features, I am talking
about:
* security issues
* licensing issues
* issues which can make cluster failing forever (is this the case with
HDDS-5118? it sounds very scary for me. This is the only one which seems
to be a bigger one)
* build time issues (it will be multiplied with ALL the PR!)
Thanks a lot,
Marton
ps: again, I really appreciate the great work, even if I have different
opinion about how the work should be finished. I think we must have this
feature on master and based on my understanding it's a very good
implementation.
I am talking about release and branch management. And I tried to show
this respect to all the contributors with sharing my concerns as
opinions not as binding negative votes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
