Agree a meeting is a good idea especially when there are fixes that are not
easily portable to 6, as pointed out by Steve I think/hope that most of the
fixes will be easily ported by simply cherry-picking them.
On Thu, 13 Dec 2018 at 17:56, Steve Ebersole <steve(a)hibernate.org> wrote:
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(a)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(a)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(a)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.
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev