> On Apr 17, 2015, at 6:26 AM, Raja Pullela <raja.pull...@citrix.com> wrote: > > +1 for the "Some people (I'm part of them) are concerned on our current way > of supporting and back porting fixes to multiple release" > This should be a top priority along with keeping master stable - make sure > BVTs are passing at 100% all the time.
Raja, which BVT are you talking about ? AFAIK, all current tests run on all commits through Travis. > Also if we can plan/target increasing test/BVT coverage, that will be super! > > Thanks, > Raja > -----Original Message----- > From: Marcus [mailto:shadow...@gmail.com] > Sent: Friday, April 17, 2015 4:35 AM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] 4.6 release management > > "storage plugin involve changes on Hypervisor code" > > I know this is just an example, but at least on KVM side this is no longer > true. Previously you had to implement a KVM-specific 'StorageAdaptor' that > would run on the hypervisor, and register that with the agent code, but Mike > and I added some reflection/annotation that allows for auto-detection of the > adaptor upon Agent start up, so storage plugins can be completely > self-contained now. They don't even have to be a part of our code base. > > There may be other parts of the code where we can do similar things to > decouple if we can identify those points. Ideally, if someone has to modify > core code to add their plugin it should only be because they are adding some > new functionality *that core cloudstack needs to be aware of*, and that > functionality should be added in a way that other plugins can also > provide/implement it. Otherwise, they can always add new APIs specific to > their appliance or product and leveraging data from cloudstack's db, all via > plugin. They can add new global/zone/cluster configs and UI tools via plugin > as well. > > On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: >> Today during the CloudStackdays we did a round table about Release >> management targeting the next 4.6 releases. >> >> >> Quick bullet point discussions: >> >> ideas to change release planning >> >> - Plugin contribution is complicated because often a new plugin involve >> change on the core: >> - ex: storage plugin involve changes on Hypervisor code >> - There is an idea of going on a 2 weeks release model which could >> introduce issue the database schema. >> - Database schema version should be different then the application >> version. >> - There is a will to enforce git workflow in 4.6 and trigger simulator >> job on PullRequest. >> - Some people (I'm part of them) are concerned on our current way of >> supporting and back porting fixes to multiple release (4.3.x, 4.4.x, >> 4.5.x). But the current level of confidence against latest release is low, >> so that need to be improved. >> >> >> So, the main messages is that w'd like to improve the release >> velocity, and release branch stability. so we would like to propose >> few change in the way we would add code to the 4.6 branch as follow: >> >> - All new contribution to 4.6 would be thru Pull Request or merge >> request, which would trigger a simulator job, ideally only if that >> pass the PR would be accepted and automatically merged. At this time, >> I think we pretty much have everything in place to do that. At a first >> step we would use >> simulator+marvin jobs then improve tests coverage from there. >> >> Please comments :-)
