Correct, I happened to find it while testing a PR of mine targeted at master.
> On Jul 17, 2018, at 1:30 PM, Rafael Weingärtner
> wrote:
>
> Correct. I do think the problem here is only in the release notes.
>
> Just to confirm, you found the problem while testing 4.12 (from master),
> right?
Correct. I do think the problem here is only in the release notes.
Just to confirm, you found the problem while testing 4.12 (from master),
right?
On Tue, Jul 17, 2018 at 4:22 PM, Tutkowski, Mike
wrote:
> Cool, if it’s just in master, then that makes it easier.
>
> Also, it means we did not
Cool, if it’s just in master, then that makes it easier.
Also, it means we did not have a process issue by introducing enhancement code
in between release candidates.
It would mean, however, that our documentation is a bit incorrect if, in fact,
it states that that feature exists in 4.11.1.
>
Ok, thanks. I had the impression that we said it was backported to 4.11.
I will get master and work on it then.
On Tue, Jul 17, 2018 at 4:12 PM, Tutkowski, Mike
wrote:
> I only noticed it in master. The example code I was comparing it against
> was from 4.11.0. I never checked against 4.11.1.
Hi, Mike, Rafael:
Thanks for the clarification of what "managed storage" is and working on fixing
the broken bits.
Yiping
On 7/16/18, 8:28 PM, "Tutkowski, Mike" wrote:
Another comment here: The part that is broken is if you try to let
CloudStack pick the primary storage on the
I only noticed it in master. The example code I was comparing it against was
from 4.11.0. I never checked against 4.11.1.
> On Jul 17, 2018, at 1:02 PM, Rafael Weingärtner
> wrote:
>
> Hey Mike, I got the branch 4.11 to start fixing the problem we discussed,
> but I do not think my commit was
Hey Mike, I got the branch 4.11 to start fixing the problem we discussed,
but I do not think my commit was backported to 4.11. I mean, I am at
"VirtualMachineManagerImpl" and the code is not here. I also checked the
commit (
I sort of agree with Marc-Aurèle and Will, and like github issues way
better than Jira.
It definitely is easier that both the issues and fix for those issues live
in the same place
and easily can be referenced from one another. The only thing is that we
need to come
up with good set of labels
Ron, keep in mind that PRs on Github are different from Issues. They are
two different features.
There will be a much cleaner, tighter integration between issues and the
solution when everything is on Github.
will
On Tue, Jul 17, 2018, 9:33 AM Ron Wheeler
wrote:
> I may have voiced my
I may have voiced my concerns earlier but as a user, I think that JIRA
issues are easier to follow than PRs.
- As Paul said an issue may affect more than one version.
- It may also require more than one PR to fully resolve the issue.
- Issues tend to be described in terms of a problem that the
Hi Paul,
My 2 cents on the topic.
people are commenting on issues when it should by the PR and vice-versa
>
I think this is simply due to the fact that with one login you can do both,
versus before you had to have a JIRA login which people might have tried to
avoid, preferring using github
Hi All,
We have been trialling replacing Jira with Github Issues. I think that we
should have a conversation about it before it become the new standard by
default.
From my perspective, I don't like it. Searching has become far more difficult,
categorising has also. When there is a bug fix
12 matches
Mail list logo
