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.s...@gmail.com> wrote: > > > > Le 6 déc. 2018 à 16:03, Sanne Grinovero <sa...@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 > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
