6:53 a.m.
Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
discussion about managing the master and 6.0 branches in terms of
commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
to perform very painful "merging" from master to 6.0. As 6.0 was in a
pre-Alpha state, that was fine. However, now that we are starting the
Alpha release cycle, that is no longer reasonable. So as of today we
really need a new strategy here. However it works out, changes made to
master than also affect 6.0 should be done in both places.
This has 2 benefits IMO:
1. Obviously it removes the need to perform these massive,
time-consuming "merges"
2. A great side effect is that it gets people with 6.0 code base
differences.
7:09 a.m.
I personally don't have a problem with that, since I don't contribute very
often, but I'd like to point out this moves most of the workload of merging
changes into 6 from Andrea/Chris to Gail/Guillaume.
Another problem being that the tests created/changed in 5.x may not work in
6 for completely different reasons (e.g. "not implemented yet"). Which will
be hard to diagnose for those not working on 6 on a day-to-day basis.
But I suppose it could work if we moved the focus away from 5.x
maintenance, which is perhaps what you had in mind?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On Thu, 6 Dec 2018 at 14:01, Steve Ebersole <steve(a)hibernate.org> wrote:
Today, I promise ;), I will release 6.0 Alpha1. But I wanted to
start a
discussion about managing the master and 6.0 branches in terms of
commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
to perform very painful "merging" from master to 6.0. As 6.0 was in a
pre-Alpha state, that was fine. However, now that we are starting the
Alpha release cycle, that is no longer reasonable. So as of today we
really need a new strategy here. However it works out, changes made to
master than also affect 6.0 should be done in both places.
This has 2 benefits IMO:
1. Obviously it removes the need to perform these massive,
time-consuming "merges"
2. A great side effect is that it gets people with 6.0 code base
differences.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:34 a.m.
In my opinion we have to distinguish between the types of issues:
- improvements, I think they must be done only in 6.0 and backported
only if it is easy
- minor bugs or bugs with a workaround, I think they should be resolved
in 6.0 (in case the feature causing the issue is not yet implemented in 6.0
he solution should be delayed ) and then backported
- critical bugs should be solved in 6.0 and 5.x in case it is too
difficult to solve them in 6.0 then just add a disabled test.
On Thu, 6 Dec 2018 at 13:17, Yoann Rodiere <yoann(a)hibernate.org> wrote:
I personally don't have a problem with that, since I don't
contribute very
often, but I'd like to point out this moves most of the workload of merging
changes into 6 from Andrea/Chris to Gail/Guillaume.
Another problem being that the tests created/changed in 5.x may not work in
6 for completely different reasons (e.g. "not implemented yet"). Which will
be hard to diagnose for those not working on 6 on a day-to-day basis.
But I suppose it could work if we moved the focus away from 5.x
maintenance, which is perhaps what you had in mind?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On Thu, 6 Dec 2018 at 14:01, Steve Ebersole <steve(a)hibernate.org> wrote:
> Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
> discussion about managing the master and 6.0 branches in terms of
> commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
> to perform very painful "merging" from master to 6.0. As 6.0 was in a
> pre-Alpha state, that was fine. However, now that we are starting the
> Alpha release cycle, that is no longer reasonable. So as of today we
> really need a new strategy here. However it works out, changes made to
> master than also affect 6.0 should be done in both places.
>
> This has 2 benefits IMO:
>
> 1. Obviously it removes the need to perform these massive,
> time-consuming "merges"
> 2. A great side effect is that it gets people with 6.0 code base
> differences.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:08 a.m.
Good points. I should have mentioned that.
At this point no new features, no improvements, no enhancements should be
done on 5. Just bug fixes.
And to be clear, I am actually fine with continuing to develop the bug
fixes on 5. The point was more about pushing something to 5 and then that
is it. We have to clearly decide as a team (1) whether that change needs
to be done on 6 and (2) how to go about that. Definitely for some period
of time I fully expect that to mean Andrea, Chris, Davide or myself being
involved in all such discussions simply because we know 6 better than
others.
Personally, I prefer developing on 6 and back-porting, but that distinction
not really relevant yet - it will become relevant as 6 gets to more of a CR
state.
On Thu, Dec 6, 2018 at 8:35 AM andrea boriero <andrea(a)hibernate.org> wrote:
In my opinion we have to distinguish between the types of issues:
- improvements, I think they must be done only in 6.0 and backported
only if it is easy
- minor bugs or bugs with a workaround, I think they should be
resolved in 6.0 (in case the feature causing the issue is not yet
implemented in 6.0 he solution should be delayed ) and then backported
- critical bugs should be solved in 6.0 and 5.x in case it is too
difficult to solve them in 6.0 then just add a disabled test.
On Thu, 6 Dec 2018 at 13:17, Yoann Rodiere <yoann(a)hibernate.org> wrote:
> I personally don't have a problem with that, since I don't contribute very
> often, but I'd like to point out this moves most of the workload of
> merging
> changes into 6 from Andrea/Chris to Gail/Guillaume.
> Another problem being that the tests created/changed in 5.x may not work
> in
> 6 for completely different reasons (e.g. "not implemented yet"). Which
> will
> be hard to diagnose for those not working on 6 on a day-to-day basis.
>
> But I suppose it could work if we moved the focus away from 5.x
> maintenance, which is perhaps what you had in mind?
>
> Yoann Rodière
> Hibernate NoORM Team
> yoann(a)hibernate.org
>
>
> On Thu, 6 Dec 2018 at 14:01, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> > Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
> > discussion about managing the master and 6.0 branches in terms of
> > commit/push. To date we (mostly Andrea and Chris, thanks guys!) have
> had
> > to perform very painful "merging" from master to 6.0. As 6.0 was in
a
> > pre-Alpha state, that was fine. However, now that we are starting the
> > Alpha release cycle, that is no longer reasonable. So as of today we
> > really need a new strategy here. However it works out, changes made to
> > master than also affect 6.0 should be done in both places.
> >
> > This has 2 benefits IMO:
> >
> > 1. Obviously it removes the need to perform these massive,
> > time-consuming "merges"
> > 2. A great side effect is that it gets people with 6.0 code base
> > differences.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:09 a.m.
Hi Steve,
I don't particularly like it.
We have very few resources to work on 5.x and clearly we won't be able to
do that + learn about 6 in parallel and fix issues in both, probably in 2
completely different ways. And we won't really be able to know if it
doesn't work because it's not implemented yet, not fully functional, same
buggy or new buggy.
We don't push that many things to 5.x so maybe you could explain why the
merges are so painful so that we can try to make them less so?
--
Guillaume
On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole <steve(a)hibernate.org> wrote:
Today, I promise ;), I will release 6.0 Alpha1. But I wanted to
start a
discussion about managing the master and 6.0 branches in terms of
commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
to perform very painful "merging" from master to 6.0. As 6.0 was in a
pre-Alpha state, that was fine. However, now that we are starting the
Alpha release cycle, that is no longer reasonable. So as of today we
really need a new strategy here. However it works out, changes made to
master than also affect 6.0 should be done in both places.
This has 2 benefits IMO:
1. Obviously it removes the need to perform these massive,
time-consuming "merges"
2. A great side effect is that it gets people with 6.0 code base
differences.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:35 a.m.
If you really "don't push that many things to 5.x", then no worries - it
does not really affect you. I suppose what you really mean is that when
you do contribute to 5 you do not want to "waste time" porting that to
6.0. Well the same is true on the flip side - while we are (very actively)
developing 6, it kind of sucks to have to waste a whole day (often more
than 1 day) to perform massive merges. There are major difference between
5 and 6 and that is part of the problem. E.g. when y'all change something
in EntityPersister, well that does not exist in 6... that's a conflict and
has to be resolved. Who is better able to resolve that? Well I think it
is a combination. The person who authored the change obviously understands
the purpose, logic, etc behind the change; far more so than the person
simply trying to integrate it. Of course most of the people doing any
development on 5 (outside of Andrea, Chris and I for the most part) do not
know the 6 code base so it is tougher for them.
The other part is that it is just logical that porting one change is far
easier than simultaneously porting many changes. That is doubly true when
you are doing one of these massive merges and there are conflicts in stuff
you did not write.
Long-story-short, putting the responsibility wholly on one party or the
other is not scalable. So far the onus has been on Andrea, Chris and I to
do that all - again, which *was* fine. But the story has changed.
What I had envisioned is that this is a collaboration. If you contribute
something to 5, ask Andrea, Chris or me (1) whether that needs to be ported
and we can work together to get it ported. Its not any different from any
"major" - when we moved from 1.0 to 2.0, or moved 2.0 to 3.0, or ... There
are always pain points due to major changes between (otherwise it would not
be a major release). And for a short time there is always a period of
"double development". I am all ears for better options; but "just develop
on 5 and let others port to 6" is simply not a good one.
On Thu, Dec 6, 2018 at 7:10 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi Steve,
I don't particularly like it.
We have very few resources to work on 5.x and clearly we won't be able to
do that + learn about 6 in parallel and fix issues in both, probably in 2
completely different ways. And we won't really be able to know if it
doesn't work because it's not implemented yet, not fully functional, same
buggy or new buggy.
We don't push that many things to 5.x so maybe you could explain why the
merges are so painful so that we can try to make them less so?
--
Guillaume
On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole <steve(a)hibernate.org> wrote:
> Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
> discussion about managing the master and 6.0 branches in terms of
> commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
> to perform very painful "merging" from master to 6.0. As 6.0 was in a
> pre-Alpha state, that was fine. However, now that we are starting the
> Alpha release cycle, that is no longer reasonable. So as of today we
> really need a new strategy here. However it works out, changes made to
> master than also affect 6.0 should be done in both places.
>
> This has 2 benefits IMO:
>
> 1. Obviously it removes the need to perform these massive,
> time-consuming "merges"
> 2. A great side effect is that it gets people with 6.0 code base
> differences.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
8:23 a.m.
Also, keep in mind that's so far we've been merging from master to 6.0. In
other words, so far any changes you have made on master have automatically
been moved to 6. That will no longer be the case moving forward. Outside
of some specific action, things pushed to 5 will not be on 6.
On Thu, Dec 6, 2018, 7:35 AM Steve Ebersole <steve(a)hibernate.org> wrote:
If you really "don't push that many things to 5.x",
then no worries - it
does not really affect you. I suppose what you really mean is that when
you do contribute to 5 you do not want to "waste time" porting that to
6.0. Well the same is true on the flip side - while we are (very actively)
developing 6, it kind of sucks to have to waste a whole day (often more
than 1 day) to perform massive merges. There are major difference between
5 and 6 and that is part of the problem. E.g. when y'all change something
in EntityPersister, well that does not exist in 6... that's a conflict and
has to be resolved. Who is better able to resolve that? Well I think it
is a combination. The person who authored the change obviously understands
the purpose, logic, etc behind the change; far more so than the person
simply trying to integrate it. Of course most of the people doing any
development on 5 (outside of Andrea, Chris and I for the most part) do not
know the 6 code base so it is tougher for them.
The other part is that it is just logical that porting one change is far
easier than simultaneously porting many changes. That is doubly true when
you are doing one of these massive merges and there are conflicts in stuff
you did not write.
Long-story-short, putting the responsibility wholly on one party or the
other is not scalable. So far the onus has been on Andrea, Chris and I to
do that all - again, which *was* fine. But the story has changed.
What I had envisioned is that this is a collaboration. If you contribute
something to 5, ask Andrea, Chris or me (1) whether that needs to be ported
and we can work together to get it ported. Its not any different from any
"major" - when we moved from 1.0 to 2.0, or moved 2.0 to 3.0, or ... There
are always pain points due to major changes between (otherwise it would not
be a major release). And for a short time there is always a period of
"double development". I am all ears for better options; but "just
develop
on 5 and let others port to 6" is simply not a good one.
On Thu, Dec 6, 2018 at 7:10 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
> Hi Steve,
>
> I don't particularly like it.
>
> We have very few resources to work on 5.x and clearly we won't be able to
> do that + learn about 6 in parallel and fix issues in both, probably in 2
> completely different ways. And we won't really be able to know if it
> doesn't work because it's not implemented yet, not fully functional, same
> buggy or new buggy.
>
> We don't push that many things to 5.x so maybe you could explain why the
> merges are so painful so that we can try to make them less so?
>
> --
> Guillaume
>
>
> On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
>> discussion about managing the master and 6.0 branches in terms of
>> commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
>> to perform very painful "merging" from master to 6.0. As 6.0 was in a
>> pre-Alpha state, that was fine. However, now that we are starting the
>> Alpha release cycle, that is no longer reasonable. So as of today we
>> really need a new strategy here. However it works out, changes made to
>> master than also affect 6.0 should be done in both places.
>>
>> This has 2 benefits IMO:
>>
>> 1. Obviously it removes the need to perform these massive,
>> time-consuming "merges"
>> 2. A great side effect is that it gets people with 6.0 code base
>> differences.
>
>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
9:03 a.m.
On Thu, 6 Dec 2018 at 13:17, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi Steve,
I don't particularly like it.
We have very few resources to work on 5.x and clearly we won't be able to
do that + learn about 6 in parallel and fix issues in both, probably in 2
completely different ways. And we won't really be able to know if it
doesn't work because it's not implemented yet, not fully functional, same
buggy or new buggy.
We don't push that many things to 5.x so maybe you could explain why the
merges are so painful so that we can try to make them less so?
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.
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 - we
need to move on towars a situation in which all innovation happens on
6 aka master.
Thanks,
Sanne
--
Guillaume
On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole <steve(a)hibernate.org> wrote:
> Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a
> discussion about managing the master and 6.0 branches in terms of
> commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had
> to perform very painful "merging" from master to 6.0. As 6.0 was in a
> pre-Alpha state, that was fine. However, now that we are starting the
> Alpha release cycle, that is no longer reasonable. So as of today we
> really need a new strategy here. However it works out, changes made to
> master than also affect 6.0 should be done in both places.
>
> This has 2 benefits IMO:
>
> 1. Obviously it removes the need to perform these massive,
> time-consuming "merges"
> 2. A great side effect is that it gets people with 6.0 code base
> differences.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:11 a.m.
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
12:36 p.m.
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
1:56 p.m.
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(a)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.
10:08 a.m.
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(a)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(a)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.
10:52 a.m.
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(a)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(a)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(a)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.
>
2:26 a.m.
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:02 a.m.
Weekly meeting sounds.
I can also help with porting things to 6.
On Fri, Dec 14, 2018 at 8:27 AM andrea boriero <andrea(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:04 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
2181
days inactive
2189
days old
15 comments
7 participants
participants (7)
-
andrea boriero -
Davide D'Alto -
Davide D'Alto -
Guillaume Smet -
Sanne Grinovero -
Steve Ebersole -
Yoann Rodiere