[hibernate-dev] master and 6.0 branch

[Steve Ebersole]

I would not even put it on Gail specifically per-se from the 5.x side.
Really we just need to be able to identify what fixes done on 5.x need to
be ported across to 6.  And then, depending on the complexity,  I would
expect some help from the person who implemented the fix in 5 porting that
change to 6 - most of the time, I'd expect to just apply those changes
myself (or Andrea or Chris).

I think a meeting is a good idea

On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Sorry for not replying earlier, got very busy on other things.
>
> So, now that we agree, how do we do things? I think we should have a
> weekly meeting at a fixed time to discuss master -> 6, probably either with
> Andrea or Chris.
>
> I could do it for a few months if it helps but in the end, I think it
> should be Gail for 5.x + whoever volunteers for the 6 part.
>
> On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I completely agree with everything you say.  A few thoughts in-line...
>>
>> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>> == What to do then
>>>
>>
>>> There are a couple of options:
>>> 1/ no workaround, then we should consider it for 5.x
>>>
>>
>> If it is fixed in 5 then it should be fixed in 6 as well.  Either it is
>> no longer a problem or because we port the fix from 5 to 6.  Not saying
>> exactly how that happens - just that that needs to be the end result.
>>
>>
>>
>>> 2/ there is a viable workaround, we can postpone it to 6, but we
>>> definitely would need to have something to mark them as we need to fix them
>>> (a version, maybe, or a tag?) - one thing is that it would probably be a
>>> good idea to categorize things a bit because when you revisit something for
>>> 6, it would be a good idea to have the existing bugs in mind as it could
>>> influence the design.
>>>
>>
>> Using a tag seems enticing, but experience tells me that won't really
>> have the effect I think you want.
>>
>>
>>
>>> * if it's something we want to fix in 6, there might be several options:
>>> 2.1/ we can already fix it in 6 because the features are already
>>> implemented
>>> 2.2/ we can't fix it right now
>>>
>>> IMHO, we should start considering taking into account 2.1/ into the
>>> daily work for 6 if we want to make this work as otherwise we will end up
>>> with a very big pile of bugs when 6 finally gets finalized.
>>>
>>
>>
>>>
>>> As for 2.2/, we should really have a way to keep track of them and push
>>> them to case 2.1/ when we can. Note that it's the same case if it's more an
>>> improvement but we consider it as something we want: if we want it, we
>>> should find a way to keep track of it somehow.
>>>
>>> That also means that we would need someone familiar with 6 to help
>>> triaging the issues. IMHO, this can be done once a week, if done regularly
>>> and steadily.
>>>
>>> If we continue fixing bugs, even in 6 only, that still says to the
>>> contributor "we hear you, we are improving". If we just stop fixing bugs
>>> until 6 is more or less feature-complete, then we send a very bad message
>>> IMHO. And we will end up with a pile of unfixed issues in the bugtracker
>>> that we won't really be able to deal with. And less users.
>>>
>>
>> Alpha1 just released the fix for HHH-37.  Yep, that's right 37 - the 37th
>> issue ever since we moved to Jira.  We *do* keep improving ;)  And that's
>> just one of the many.
>>
>> But yes your point is valid.  It is very important to keep fixing bugs.
>>
>