If it's a matter of reviewing code, I'm happy to help. In that case, my
name should be added as a reviewer.
BTW, I forget to check all the various ways I can be contacted, so a
personal email or hipchat message. helps.
On Tue, Jan 30, 2018 at 5:52 AM, Sanne Grinovero
wrote:
> In some cases - ma
In some cases - maybe not these specifically - I know people ask your
review when it gets tricky, as you're the most thorough reviewer and
have deep knowledge of most areas :) Maybe that was the case, maybe
not. Good to clarify either way.
Thanks!
Sanne
On 30 January 2018 at 00:59, Gail Badner
I've seen at least one jira comment asking if I approve backporting to 5.2,
and I also remember seeing a PR that had "Requires Gail" label with a
comment suggesting bugfixes in older branches (including 5.2) must be
approved by me.
I just wanted to make this clear so that bugfixes that should be b
I don't think anyone mentioned expecting you to do this. In fact the
discussions I have had about this was that others would help with this
(after 5.2.13).
On Wed, Jan 24, 2018 at 5:20 PM Gail Badner wrote:
> People seem to be relying on me to backport to 5.2. From a product
> standpoint, ther
I don't know how applicable this is to the Hibernate project, but a
workflow I've seen is you do the fixes in the old maintenance-only branches
(say 5.1) and then merge or cherry-pick those changes into the
current-release branch. Of course if they've diverged too drastically in
very few commits, t
For what it's worth, +1 on this. At least back in the day, we'd
continue to backport bugfixes to the previous minor release, until a new
final minor release was deployed. That was the responsibility of
whoever was committing to master. Since the baselines were typically
"close enough", commi
