[hibernate-dev] master and 6.0 branch

[andrea boriero]

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 at 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 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.
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>