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 wrote:
>
> Weekly meeting sounds.
> I can also help with porting things to 6.
>
>
> On Fri, Dec 14,
Weekly meeting sounds.
I can also help with porting things to 6.
On Fri, Dec 14, 2018 at 8:27 AM andrea boriero 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 eas
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 wrote:
> I would not even put it on Gail
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
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
sh
I completely agree with everything you say. A few thoughts in-line...
On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet
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
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 o
> Le 6 déc. 2018 à 16:03, Sanne Grinovero 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.
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
On Thu, 6 Dec 2018 at 13:17, Guillaume Smet 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 rea
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 imp
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
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)
develo
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 dif
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 implemente
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
16 matches
Mail list logo
