I don't think creating a branch will help in releasing faster. It
will only make it worse in my opinion.
If we can release faster, features will stay in the PR branch for
a short while and can be merged quickly.
~ Rajani
http://cloudplatform.accelerite.com/
On June 28, 2017 at 12:17 PM, Daan Ho
Those new PRs should not have been merged.
Those on the mailing list should respect the process and accept that they will
have to wait until code is unfrozen.
Kind regards,
Paul Angus
paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
I'm with Mike on this. fixes go into the rc branch, features don't and
that's a clearer line then we have now. or we could just keep rc'ing
untill one passes and keep working on stablising whichever branch we
choose for that allowing both features and fixes.
On Wed, Jun 28, 2017 at 8:40 AM, Tutkow
Paul,
Which shows we are not actively following RCs. That PR was a
blocker for RC3 and was well discussed. That PR is a perfect
example that we are not working as community to release code.
That is a fix for a blocker which stayed open for more than 45
days.
If you see till RC2 it was only blocke
Hi,
I personally still like the idea of a new branch being created right around the
time we cut our first RC.
Even if people want to commit changes to the new branch, they should understand
that that code won't be formally released until the pending RC is validated and
released.
That being th
Rajani,
I suspect that fatigue with the 4.10 release testing that we are seeing is due
to the time it has taken to release it. And that is has been caused by new
code going in, which have introduced new bugs.
This was demonstrated in the last -1 from Kris. This change was merged 10 days
ago.
We can do a release every month as long as we have enough people
actively participating in the release process.
We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on
releases/blockers. How many of us are testing/voting on releases
or
Hi Kris,
Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.
Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would he
I'm glad you guys (Paul and Rafael) agree with me. We should cut a branch once
the first RC is built. Then we should only allow blockers in to fix RC issues.
This should speed up our releases in the future.
> On Jun 27, 2017, at 10:14 AM, Rafael Weingärtner
> wrote:
>
> +1 to what Paul said.
+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a version, all
merges should stop (period); the only exceptions should be PRs that address
specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for this
version, we have not followed it?
Hi all,
I 'm sorry for voting -1 again.
Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980
Caused by : https://github.com/apache/cloudstack/pull/2089
Fixed by : https://github.com/apache/cloudstack/pull/2162
Kris
- Nuage Networks
On 26 June 2017 at 18:58, Tutkowski, Mike wrote:
Hi Giles,
I could give a talk on live migration with KVM that we have since one year
here. That might help to get the feature fixed and merged for CS. Let me
know.
https://github.com/apache/cloudstack/pull/1709
Marc-Aurèle
On Thu, Jun 22, 2017 at 1:41 PM, Wido den Hollander wrote:
> Hi,
>
> Re
12 matches
Mail list logo
