Re: [hibernate-dev] master and 6.0 branch
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(a)gmail.com>
wrote:
> Le 6 déc. 2018 à 16:03, Sanne Grinovero <sanne(a)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