[hibernate-dev] master and 6.0 branch

[Guillaume Smet]

Gave it some thoughts while walking a bit.

Note: it's just my personal opinion so sharing as such.

IMHO, there are a couple of important things:

== Triaging

We need to keep triaging bugs that are created: this is *very* important
because otherwise it will just be a pile of issues added on top of the
others.

That means:
- asking for test cases if there is not
- check the test case and validate it's a bug, it's not always obvious
- decide if we want to fix it

== What to do then

There are a couple of options:
1/ no workaround, then we should consider it for 5.x
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.
* 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.

The very important thing IMHO is "taking into account 2.1/ into the daily
work for 6". That means 6 development should also include bug fixing of
incoming bugs, not only implement missing features.

-- 
Guillaume

On Thu, Dec 6, 2018 at 6:11 PM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

>
>
> > Le 6 déc. 2018 à 16:03, Sanne Grinovero <sanne at hibernate.org> a écrit :
> > It's 200,000 lines of code difference. Just don't make any change on 5
> > - it's not a good use of our time either, since the future is 6.
>
> Make 5.x a dead branch is not a good option.
>
> Especially, since we don’t know when we will release 6.
>
> We already reduced to the bare minimum the effort spent on 5.x.
>
> But answering users, reproducing their bugs and fixing them is not a waste
> of time.
>
> Even for 6 as that means we have a test case of something that’s validated
> as supposed to work.
>
> And it can also nourish the 6 design.
>
> > As you said in the previous paragraph, we're a small team and we can't
> > keep developing 2 branches of the same project.
> >
> > 5.x needs to be moved into strictly maintenance only, so please stop
> > pushing big changes to 5.x unless there's a very important reason
>
> You say that as if we pushed big changes to 5.x lately.
>
> That’s not the case.
>
> Now if you ask me if we should have a more strict bug fix only policy on
> 5.x, I couldn’t agree more.
>
> That’s what I asked for the CR. I wanted it to be even more strict for CR
> = only regressions from 5.3.
>
> Couldn’t get it to be respected though.
>
> —
> Guillaume
>
>
>