We need a distributed QA framework, where folks with all kind of setups
- fetch code continuously, build cloudstack, run tests, sanitize outputs
and submit upstream.
Some folks on this list would want to remain anonymous, but this build,
deploy, test and submit results process needs to be automated. Would be
a great project for GSOC interns.
On 4/22/15 2:51 AM, S. Brüseke - proIO GmbH wrote:
In my opinion we need to improve QA! If smaller cycles will help to do that this is the
way to go. I joined this list after the "release" of 4.5, but as far as I know
4.5 is not really usable for production because of critical bugs in it that good QA would
not have passed.
So if CS releases new version every 2 month with just a few new features, but
these are working, it would be great. We also can do some bug fixing and
code-cleaning too.
My $.002
Mit freundlichen Grüßen / With kind regards,
Swen Brüseke
-----Ursprüngliche Nachricht-----
Von: Remi Bergsma [mailto:[email protected]]
Gesendet: Mittwoch, 22. April 2015 11:25
An: [email protected]
Betreff: Re: Next ACS release?
I'd be happy to help here as well. Last week in Austin, we also discussed this
topic a couple of times. I do agree shorter release cycles are better.
In my opinion, the first thing to improve is the minor releases in both the
4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we
will be able to do the next minor release with less effort and users can choose
to either wait to start using 4.5 or start now and upgrade when the next minor
release is available. This would have helped in getting 4.5 out on time and
quickly fixing issues after the initial release. Also, it will save time which
we can invest in getting the next release out on time, etc.
The common thing here is we need more automated testing, preferably functional
testing in addition to unit testing. There might also be other steps that we do
manually now that can be automated. I'll try to understand the current process
first and then come up with a proposal to improve which we can discuss.
Regards,
Remi
2015-04-22 10:56 GMT+02:00 Erik Weber <[email protected]>:
On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
<[email protected]>
wrote:
On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber <[email protected]>
wrote:
On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
[email protected]>
wrote:
I have to admit I'm a bit sceptical because when we did have a
four-month
release cycle, we never seemed to manage to meet it. Personally I
think
six-monthly might be easier.
Having said that, part of the problem was the long close-down
period
where
we kept finding critical bugs, so more automated testing might
help to shorten the cycle.
- Shorter cycle means that it's less of a problem to miss a
deadline, meaning you can spend more time on QA.
- Longer cycle means that it could be critical to meet the
deadline, meaning you might end up doing less QA while stressing
to get your
feature
in.
My $.002
Yes, Eric and the amount of qa needed is less as well. Bare with me
for a little rant here.
When less new features are introduced less new interdependencies are
introduced. I could try and expand on this but people make phd on
the subject so that would be presumptuous of me.
un-educated guess is (m + n)! - m!
where m is old features and n is new features
example:
1 old feature + 1 new feature mean 1 check to see if they (still)
work
1 old feature + 2 new features means 3 checks to see if they all
work
2 + 2 = 6 of which only 1 is old and should be fine
2 + 3 = 10, see the n! progressing ;)
this is an over simplification as the complexity of features comes
in play as well. I make them out for being function points here.
those are fables of course.
thanks for baring that.
I'm all with you on this Daan.
Just for the record, my notion of QA was meant at the feature
developer, ie. that they could use more time on test coverage etc.
without having to worry that much about feature freeze dates.
--
Erik
- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main
USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht
gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify
the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
