[hibernate-dev] master and 6.0 branch

[Davide D'Alto]

Weekly meetings sounds.
I can also help with porting things to 6.

PS: Sorry if you have received 2 emails, I used the wrong address in
the first one.
On Fri, Dec 14, 2018 at 11:02 AM Davide D'Alto <daltodavide at gmail.com> wrote:
>
> Weekly meeting sounds.
> I can also help with porting things to 6.
>
>
> On Fri, Dec 14, 2018 at 8:27 AM andrea boriero <andrea at hibernate.org> wrote:
> >
> > 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
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev