We're at the stage of the release cycle where we should be committing
critical fixes only to the 2.1 branch. Many people depend on 2.1 working
reliably and it's not worth the risk of introducing regressions for (e.g.)
performance improvements.
I think some of the patches committed so far for 2.1.
Looking at those tickets in all three of them the “is this critical to fix”
question came up in the JIRA discussion and it was decided that they were
indeed critical enough to commit to 2.1.
> On Jul 18, 2016, at 11:47 AM, Jonathan Ellis wrote:
>
> We're at the stage of the release cycle where
Except there really wasn't.
Patch submitter: "I want this in 2.1."
Reviewer: "Okay."
That's not exactly the bar we're looking for. To consider a performance
fix "critical" for example, you really need to show at the very least what
new workload you found that isn't able to live with it the way e
So much for compaction of information eh?
On Tuesday, July 12, 2016 10:06 AM, Pedro Gordo
wrote:
Hi
Yes, I just saw Marcus reply now, sorry for the duplicate email. The email
filters were not set up correctly. Thanks to both!
Best regards
Pedro Gordo
On 12 July 2016 at 12:39, Robe
Dev discussion about the project should ideally be on the dev list.
Further, all *decisions* must be on the dev list for the project.
JIRA has the negative impact that it is lost in many people’s email
filters and hard to parse the signal from the noise.
I would consider some well formed emails t
