[mantisbt-dev] Staging 1.3 for release

Discussion:

Victor Boctor

2014-09-19 03:39:24 UTC

Hi all,

It has become a habit to discuss this topic every couple of month. I'm
seeing there is a lot of activity in terms of checkins, but I want us to
make sure we are on a path to getting 1.3 out of the door. We have always
been a month or two away with desire to get some more stuff in.

At the moment, there is a lot of churn on master that can be classified as
good change, but not really needed for 1.3 to go out.

I would like to suggest staging 1.3 as follows:

- Branch for 1.3
- Upgrade our bug tracker to 1.3 branch.
- Put this branch in bug fix only mode.

That would give us the following benefits:

- A better chance at stabilizing (based on blocking bugs) and releasing.
- Ability to release 1.3 beta/alpha and get more testing.
- Continue doing back porting of good changes, but are not critical to 1.3
release without destabilizing.
- Unblock 2.0 changes

Hope that makes sense.

Thanks,
-Victor

Paul Richards

2014-09-19 07:58:16 UTC

Permalink

My suggestion on this 2 weeks ago that was sent to the mailing list was:

"Iâd like to see us pick a date to branch 1.3 for release, say 31st October
2014 (to give a chance to get all patches that already exist for 1.3
merged), and then say 1st January 2015 for 2.0."

Post by Victor Boctor
Hi all,
It has become a habit to discuss this topic every couple of month. I'm
seeing there is a lot of activity in terms of checkins, but I want us to
make sure we are on a path to getting 1.3 out of the door. We have always
been a month or two away with desire to get some more stuff in.
At the moment, there is a lot of churn on master that can be classified as
good change, but not really needed for 1.3 to go out.
- Branch for 1.3
- Upgrade our bug tracker to 1.3 branch.
- Put this branch in bug fix only mode.
- A better chance at stabilizing (based on blocking bugs) and releasing.
- Ability to release 1.3 beta/alpha and get more testing.
- Continue doing back porting of good changes, but are not critical to 1.3
release without destabilizing.
- Unblock 2.0 changes
Hope that makes sense.
Thanks,
-Victor
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Roland Becker

2014-09-19 09:50:53 UTC

Permalink

Victor,

I mentioned some time before that I would like to see the branch _after_ 1.3.0
or even better 1.3.1
This is to avoid the additional work that is needed to implement fixes for two
branches.
It seems that you don't consider this approach.

Ok, at least we shouldn't branch before the fixes for let's say the second
official beta version are implemented and at least the following issues [1] are
fixed.

I fear that we will see quite soon some commits from Victor and Paul in master
after the branch has been created that will complicate porting changes from 1.3
to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs
in 1.3 and port them to 2.0.

Roland Becker

2014-09-19 11:22:30 UTC

Permalink

Wrong link for [1]
Should have been
http://www.mantisbt.org/bugs/search.php?project_id=1&status_id[]=10&status_id[]=20&status_id[]=30&status_id[]=40&status_id[]=50&severity_id[]=60&severity_id[]=70&severity_id[]=80&sticky_issues=on&target_version=1.3.x&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0

Post by Roland Becker
Victor,
I mentioned some time before that I would like to see the branch _after_ 1.3.0
or even better 1.3.1
This is to avoid the additional work that is needed to implement fixes for two
branches.
It seems that you don't consider this approach.
Ok, at least we shouldn't branch before the fixes for let's say the second
official beta version are implemented and at least the following issues [1] are
fixed.
I fear that we will see quite soon some commits from Victor and Paul in master
after the branch has been created that will complicate porting changes from 1.3
to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs
in 1.3 and port them to 2.0.

Damien Regad

2014-09-19 14:48:50 UTC

Permalink

Post by Victor Boctor
It has become a habit to discuss this topic every couple of month.

Not sure if I should :-) or :-(...

Post by Victor Boctor
At the moment, there is a lot of churn on master that can be classified
as good change, but not really needed for 1.3 to go out.

Fully agreed.

I'd also like to point out that we have several security issues pending a
fix since May, but the assigned developer is currently focusing on seemingly
more important activities at the moment :-P

Furthermore, several of the recent changes are adding instability and even
introduced regressions. As things stand, the current continuous stream of
changes is only delaying a potential go-live.

Post by Victor Boctor
- Branch for 1.3

Roland's answer has pretty much covered my opinion on this already, and
perfectly outlined the consequences of doing it.

Therefore, and for the same reasons, I *strongly oppose early branching*.

We MUST NOT branch before at least 1.3.0b1 is out (so we can reach some
level of stability) and SHOULD NOT do it until 1.3.0.

Post by Victor Boctor
- Upgrade our bug tracker to 1.3 branch.

As mentioned by Roland, we need to ensure our plugins have no issues with that.

Post by Victor Boctor
Did someone test that all plugins running on mantisbt.org/bugs are
running fine

I did actually. At the moment, the *source integration* does NOT work
properly, effectively blocking a move to mantisbt.org for now. I have a
local work-in-progress branch where I attempt to fix the issues but I'm not
done yet.

Furthermore, before we upgrade our tracker, I would like everyone in the
team to actually spend some time to perform in-depth "pre-alpha" tests
locally, including coverage of upgrade scenarios, and reporting results of
the same.

Post by Victor Boctor
- Put this branch in bug fix only mode.

This is kind of out of the equation for now considering my position above,
but +1 on principle.

Post by Victor Boctor
- A better chance at stabilizing (based on blocking bugs) and releasing.
- Ability to release 1.3 beta/alpha and get more testing.
- Continue doing back porting of good changes, but are not critical to 1.3

release without destabilizing.

Post by Victor Boctor
- Unblock 2.0 changes

Victor Boctor

2014-09-19 14:59:22 UTC

Permalink

@paul, I saw your message to the mailing list, but I'm thinking it is good
to discuss in a dedicated thread (this thread). We have to weigh the
benefit of merging all existing patches in 1.3, vs. some in 1.3 and some in
2.0.

@atrol, I remember your preference. I'm mainly reacting to the fact that
just earlier this year, we had a goal of releasing 1.3 beta by end of
January (with several targets before then). I think to get it out, we have
to have a bar of what can make it into 1.3. We seem to be in a cycle of
adding stuff and then fixing bugs introduced by the added stuff, etc. So
whether we branch or not, we need to have such bar (e.g. functional bug
fixes or bug fixes to blocking / security bugs, etc).

As for adding new features vs. fixing bugs. We should start with the
person who added a feature handling its bugs. That won't cover bugs that
requires investigation of the even the area causing the issue, but should
be a good starting point.

Given history I believe a timeline of 1.3 in October and 2.0 in January is
unrealistic (impossible). I feel we really need to schedule some hard stop
in our timeline, otherwise, we will keep going for a very long time without
releases.

Given @atrol and @dregad's preference, I'm OK with not branching until the
first beta release is out (at least), but we need to agree on the bar.

- blocking bug fixes
- functional bug fixes
- security bugs

So for submitted pull requests, we are not going to just look into whether
the change is OK, but does it just cause churn and delay 1.3. I would
suggest applying this policy to pull requests in flight and future ones.

Once @dregad gets the source control plugin working, then we can upgrade
our instance and move forward.

Post by Damien Regad

Post by Victor Boctor
It has become a habit to discuss this topic every couple of month.

Not sure if I should :-) or :-(...

Post by Victor Boctor
At the moment, there is a lot of churn on master that can be classified
as good change, but not really needed for 1.3 to go out.

Fully agreed.
I'd also like to point out that we have several security issues pending a
fix since May, but the assigned developer is currently focusing on seemingly
more important activities at the moment :-P
Furthermore, several of the recent changes are adding instability and even
introduced regressions. As things stand, the current continuous stream of
changes is only delaying a potential go-live.

Post by Victor Boctor
- Branch for 1.3

Roland's answer has pretty much covered my opinion on this already, and
perfectly outlined the consequences of doing it.
Therefore, and for the same reasons, I *strongly oppose early branching*.
We MUST NOT branch before at least 1.3.0b1 is out (so we can reach some
level of stability) and SHOULD NOT do it until 1.3.0.

Post by Victor Boctor
- Upgrade our bug tracker to 1.3 branch.

As mentioned by Roland, we need to ensure our plugins have no issues with that.

Post by Victor Boctor
Did someone test that all plugins running on mantisbt.org/bugs are
running fine

I did actually. At the moment, the *source integration* does NOT work
properly, effectively blocking a move to mantisbt.org for now. I have a
local work-in-progress branch where I attempt to fix the issues but I'm not
done yet.
Furthermore, before we upgrade our tracker, I would like everyone in the
team to actually spend some time to perform in-depth "pre-alpha" tests
locally, including coverage of upgrade scenarios, and reporting results of
the same.

Post by Victor Boctor
- Put this branch in bug fix only mode.

This is kind of out of the equation for now considering my position above,
but +1 on principle.

1.3
release without destabilizing.

Post by Victor Boctor
- Unblock 2.0 changes

+1 in theory... However as Roland pointed out, I think we unfortunately know
from past experience what would likely happen in such a scenario. And quite
frankly I'm not prepared to spend the same amount of effort as I did in the
past to maintain 1.3.x <==> 2.0.x ports.
Bottomline: I propose that we
- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and
- resume the new features fest after 1.3.0a1 is out.
Damien
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

P Richards

2014-09-19 21:04:23 UTC

Permalink

Roland,

I think the initial with the 1.2 and historical fixes was that we didn't have plan post 1.2.

In terms of 1.3, I'd like to see us support this longer term, so I think it would be good to see us bug port more bug fixes.

I've not had much time so far in September to spend on Mantis Development, as I work in a school and the first few weeks are really busy.

Now that the first few weeks are done, I should be able to dedicate more time towards mantis. At the moment, I'm going through existing patches that people offered to help get committed from next/master-2.x before we look at 1.3.

You'll probably see the pace of that development accelerate over the next month as I'll have some free time to work on Mantis, coupled with some free work time to throw in.

Hopefully we can get as much merged as possible to reduce both the work in keeping the patches sync'd up to the current master, and to avoid having what we've had before of doing a release and then having massive churn on master.

I will have pull requests for every patch against master-2 / next in github within the next 7-10 days.

This will allow us to delete the historical next/master-2.x branches.

I've then got 2-3 new features that I'd like to put forward in October, and plan to spend some time trying to stabilise master for a release at that point.

I suggested two weeks ago that we set a date of end of October for new development - when I said " to branch 1.3 for release" - I meant for an alpha release, and not for a final release.

In terms of 'when to branch' - we should branch master into 1.3 before the first alpha release. But equally, that should be done at the point everyone's had a chance to get any changes in before the branch. Whilst I know that I've not had much time to dedicate to Mantis for the last month, and I know I'm about to get a chunk of time to spend on mantis for the next month, others may have different schedules. The rational for saying we should set an "end of October" or even "end of November" date or similar timescale was to give everyone a chance to finalise any patches before we move to a period of stabilisation.

Paul

-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 19 September 2014 10:51
To: developer discussions; Victor Boctor
Subject: Re: [mantisbt-dev] Staging 1.3 for release

Victor,

I mentioned some time before that I would like to see the branch _after_ 1.3.0 or even better 1.3.1 This is to avoid the additional work that is needed to implement fixes for two branches.
It seems that you don't consider this approach.

Ok, at least we shouldn't branch before the fixes for let's say the second official beta version are implemented and at least the following issues [1] are fixed.

I fear that we will see quite soon some commits from Victor and Paul in master after the branch has been created that will complicate porting changes from 1.3 to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs in 1.3 and port them to 2.0.

Victor Boctor

2014-09-21 22:32:31 UTC

Permalink

Paul, the goal is not to pull all the changes in 2.0/next. We avoided these branches to reduce the churn to enable 1.3 going out and to be able to review the changes. You porting these changes fixed the latter, but not the churn problem.

@dregad’s suggestion:

- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and
- resume the new features fest after 1.3.0a1 is out.

@vboctor’s suggestion:

- blocking bug fixes
- functional bug fixes
- security bugs

Branching to be discussed after 1.3a1 is out.

Let’s focus on stablization, upgrading our tracker and getting 1.3.0a1/b1 out.

I’ve started doing some testing on master and adding some 1.3 support to plugins that I authored or contributed to.

I’ll also start responding to pull requests based on the above criteria since at least 3 of us seem to be on board with it.

Post by Damien Regad
Roland,
I think the initial with the 1.2 and historical fixes was that we didn't have plan post 1.2.
In terms of 1.3, I'd like to see us support this longer term, so I think it would be good to see us bug port more bug fixes.
I've not had much time so far in September to spend on Mantis Development, as I work in a school and the first few weeks are really busy.
Now that the first few weeks are done, I should be able to dedicate more time towards mantis. At the moment, I'm going through existing patches that people offered to help get committed from next/master-2.x before we look at 1.3.
You'll probably see the pace of that development accelerate over the next month as I'll have some free time to work on Mantis, coupled with some free work time to throw in.
Hopefully we can get as much merged as possible to reduce both the work in keeping the patches sync'd up to the current master, and to avoid having what we've had before of doing a release and then having massive churn on master.
I will have pull requests for every patch against master-2 / next in github within the next 7-10 days.
This will allow us to delete the historical next/master-2.x branches.
I've then got 2-3 new features that I'd like to put forward in October, and plan to spend some time trying to stabilise master for a release at that point.
I suggested two weeks ago that we set a date of end of October for new development - when I said " to branch 1.3 for release" - I meant for an alpha release, and not for a final release.
In terms of 'when to branch' - we should branch master into 1.3 before the first alpha release. But equally, that should be done at the point everyone's had a chance to get any changes in before the branch. Whilst I know that I've not had much time to dedicate to Mantis for the last month, and I know I'm about to get a chunk of time to spend on mantis for the next month, others may have different schedules. The rational for saying we should set an "end of October" or even "end of November" date or similar timescale was to give everyone a chance to finalise any patches before we move to a period of stabilisation.
Paul
-----Original Message-----
Sent: 19 September 2014 10:51
To: developer discussions; Victor Boctor
Subject: Re: [mantisbt-dev] Staging 1.3 for release
Victor,
I mentioned some time before that I would like to see the branch _after_ 1.3.0 or even better 1.3.1 This is to avoid the additional work that is needed to implement fixes for two branches.
It seems that you don't consider this approach.
Ok, at least we shouldn't branch before the fixes for let's say the second official beta version are implemented and at least the following issues [1] are fixed.
I fear that we will see quite soon some commits from Victor and Paul in master after the branch has been created that will complicate porting changes from 1.3 to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs in 1.3 and port them to 2.0.
Some developers had certainly some pleasure to add new stuff to master / next /
2.0 whereas other developers had not that much pleasure to fix hundreds of bugs in 1.2.x and to port the fixes to master.
To get a rough impression of what I mean, check "Assigned To" from [2]
dregad 264
rombert 102
atrol 45
vboctor 31 (even less if you don't count the issues driven by MantisTouch) grangeway 5
I hope we will not see the same story for 1.3.
Did someone test that all plugins running on mantisbt.org/bugs are running fine with current master?
Maybe some of them can/should be deactivated.
At least "Source control integration" and "Snippets" should work.
Roland
[1]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
[2]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]=1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_version[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fixed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version[]=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_version[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide_status_id=-2&match_type=0

Post by Victor Boctor
Hi all,
It has become a habit to discuss this topic every couple of month.
I'm seeing there is a lot of activity in terms of checkins, but I want
us to make sure we are on a path to getting 1.3 out of the door. We
have always been a month or two away with desire to get some more stuff in.
At the moment, there is a lot of churn on master that can be
classified as good change, but not really needed for 1.3 to go out.
- Branch for 1.3
- Upgrade our bug tracker to 1.3 branch.
- Put this branch in bug fix only mode.
- A better chance at stabilizing (based on blocking bugs) and releasing.
- Ability to release 1.3 beta/alpha and get more testing.
- Continue doing back porting of good changes, but are not critical to
1.3 release without destabilizing.
- Unblock 2.0 changes
Hope that makes sense.
Thanks,
-Victor
----------------------------------------------------------------------
-------- Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
clktrk_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Paul Richards

2014-09-21 22:51:22 UTC

Permalink

Hi Victor,

Indeed - there's a number of changes from 2.0/next branches that I'm not
pulling across at this stage. For example 'bug objects' and "MantisContext"
work ( the 2nd at least, I think roland quite liked)

As I said to roland's reply, I'd like to see us ensure a good quality 1.3
release. At the moment, I don't think we are ready to achieve that.

I've already said the timescale I think we should work too in terms of new
code and fixing stuff - end of October.

In any case, I'm going to be doing several pull requests a day until end of
October and at that point will be stopping and focusing on bug-fixing and
testing for a good quality 1.3 release.

Hopefully by that point we'll have a new build system in place, and enhanced
phpunit tests which should aid the testing process.

Paul

-----Original Message-----
From: Victor Boctor [mailto:***@gmail.com]
Sent: 21 September 2014 23:33
To: Paul Richards
Cc: MantisBT Dev Mailing List
Subject: Re: [mantisbt-dev] Staging 1.3 for release

Paul, the goal is not to pull all the changes in 2.0/next. We avoided these
branches to reduce the churn to enable 1.3 going out and to be able to
review the changes. You porting these changes fixed the latter, but not the
churn problem.

@dregad's suggestion:

- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and
- resume the new features fest after 1.3.0a1 is out.

@vboctor's suggestion:

- blocking bug fixes
- functional bug fixes
- security bugs

Branching to be discussed after 1.3a1 is out.

Let's focus on stablization, upgrading our tracker and getting 1.3.0a1/b1
out.

I've started doing some testing on master and adding some 1.3 support to
plugins that I authored or contributed to.

I'll also start responding to pull requests based on the above criteria
since at least 3 of us seem to be on board with it.

Post by Damien Regad
Roland,
I think the initial with the 1.2 and historical fixes was that we didn't have plan post 1.2.
In terms of 1.3, I'd like to see us support this longer term, so I think

it would be good to see us bug port more bug fixes.

Post by Damien Regad
I've not had much time so far in September to spend on Mantis Development,

as I work in a school and the first few weeks are really busy.

Post by Damien Regad
Now that the first few weeks are done, I should be able to dedicate more

time towards mantis. At the moment, I'm going through existing patches that
people offered to help get committed from next/master-2.x before we look at
1.3.

Post by Damien Regad
You'll probably see the pace of that development accelerate over the next

month as I'll have some free time to work on Mantis, coupled with some free
work time to throw in.

Post by Damien Regad
Hopefully we can get as much merged as possible to reduce both the work in

keeping the patches sync'd up to the current master, and to avoid having
what we've had before of doing a release and then having massive churn on
master.

Post by Damien Regad
I will have pull requests for every patch against master-2 / next in

github within the next 7-10 days.

Post by Damien Regad
This will allow us to delete the historical next/master-2.x branches.
I've then got 2-3 new features that I'd like to put forward in October,

and plan to spend some time trying to stabilise master for a release at that
point.

Post by Damien Regad
I suggested two weeks ago that we set a date of end of October for new

development - when I said " to branch 1.3 for release" - I meant for an
alpha release, and not for a final release.

Post by Damien Regad
In terms of 'when to branch' - we should branch master into 1.3 before the

first alpha release. But equally, that should be done at the point
everyone's had a chance to get any changes in before the branch. Whilst I
know that I've not had much time to dedicate to Mantis for the last month,
and I know I'm about to get a chunk of time to spend on mantis for the next
month, others may have different schedules. The rational for saying we
should set an "end of October" or even "end of November" date or similar
timescale was to give everyone a chance to finalise any patches before we
move to a period of stabilisation.

Post by Damien Regad
Paul
-----Original Message-----
Sent: 19 September 2014 10:51
To: developer discussions; Victor Boctor
Subject: Re: [mantisbt-dev] Staging 1.3 for release
Victor,
I mentioned some time before that I would like to see the branch _after_

1.3.0 or even better 1.3.1 This is to avoid the additional work that is
needed to implement fixes for two branches.

Post by Damien Regad
It seems that you don't consider this approach.
Ok, at least we shouldn't branch before the fixes for let's say the second

official beta version are implemented and at least the following issues [1]
are fixed.

Post by Damien Regad
I fear that we will see quite soon some commits from Victor and Paul in

master after the branch has been created that will complicate porting
changes from 1.3 to 2.0.

Post by Damien Regad
I fear also, that Victor and Paul will not invest that much time in fixing

bugs in 1.3 and port them to 2.0.

Victor Boctor

2014-09-21 23:24:29 UTC

Permalink

I don’t think you are hearing what the team is saying… I know what are you saying, but I don’t think the team is on board with it. I wanted to branch, the team wasn’t on board. I decide to compromise and re-discuss after 1.3.0a1 is out.

We need to have a criteria to accept / reject these pull requests, and my feel based on the thread so far, is that if you just keep porting stuff, there will be good portion that won’t make sense to pass the pull request phase.

Reviewing these pull requests also takes time, so lets make sure that we are making good use of everyone’s time.

If we decide to accept all your pull requests, then we might as well open it for all to get in whatever they have time to get in.

I disagree with the statement about 1.3 not about to quality bar yet, and your checkins are making it better. A lot of the changes are good changes but are not fixing issues that affect our ability to ship 1.3. Or even fixing a bug that an end user would benefit from.

Now if I’m wrong about that, then feel free to present your case in each of the pull requests.

Post by Paul Richards
Hi Victor,
Indeed - there's a number of changes from 2.0/next branches that I'm not
pulling across at this stage. For example 'bug objects' and "MantisContext"
work ( the 2nd at least, I think roland quite liked)
As I said to roland's reply, I'd like to see us ensure a good quality 1.3
release. At the moment, I don't think we are ready to achieve that.
I've already said the timescale I think we should work too in terms of new
code and fixing stuff - end of October.
In any case, I'm going to be doing several pull requests a day until end of
October and at that point will be stopping and focusing on bug-fixing and
testing for a good quality 1.3 release.
Hopefully by that point we'll have a new build system in place, and enhanced
phpunit tests which should aid the testing process.
Paul
-----Original Message-----
Sent: 21 September 2014 23:33
To: Paul Richards
Cc: MantisBT Dev Mailing List
Subject: Re: [mantisbt-dev] Staging 1.3 for release
Paul, the goal is not to pull all the changes in 2.0/next. We avoided these
branches to reduce the churn to enable 1.3 going out and to be able to
review the changes. You porting these changes fixed the latter, but not the
churn problem.
- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and
- resume the new features fest after 1.3.0a1 is out.
- blocking bug fixes
- functional bug fixes
- security bugs
Branching to be discussed after 1.3a1 is out.
Let's focus on stablization, upgrading our tracker and getting 1.3.0a1/b1
out.
I've started doing some testing on master and adding some 1.3 support to
plugins that I authored or contributed to.
I'll also start responding to pull requests based on the above criteria
since at least 3 of us seem to be on board with it.

Post by Damien Regad
Roland,
I think the initial with the 1.2 and historical fixes was that we didn't

have plan post 1.2.

Post by Damien Regad
In terms of 1.3, I'd like to see us support this longer term, so I think