cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: 4.5 RM
Date Tue, 19 Aug 2014 18:00:35 GMT
There is another apache project using github model, I said in another mail thread: https://wiki.apache.org/cordova/GitWorkflow.

Please, let's take action, and move forward, to solve the long time issue around Apache CloudStack:
no code review, no CI.
Should we start another around of discussion about code review and CI? 

> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Tuesday, August 19, 2014 10:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.5 RM
> 
> >
> > IMHO we should not even release 4.5 until we have a agreed upon:
> >
> > -what our issues are and why we released 4.4 and 4.3 late.
> > -taken action to resolve those issues
> > -guarantees that 4.5 will be on time
> >
> > If we don't do that, I don't even know why we are putting ourselves
> through the pain of a release schedule.
> >
> 
> So I've been trying to give this some thought. Here's my current line of
> thinking.
> 
> The issues with late releases are not a function of our release process per se;
> but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points that interact
> with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for new
> features, but the range of options is so large that testing everything is a bit
> difficult. When someone makes a merge request; I suspect few people do
> much looking. Understandable, it's a boring task; and really looking doesn't
> tell us much except for style and egregious errors. We've rarely done
> mandatory testing of feature branches before they are merged in. If you
> want to ship on time, you must ensure that we are vociferously guarding the
> quality of the master and release branches; that we can verify
> programmatically that a commit or merge doesn't break things. We must
> insist on automated testing being added.
> 
> So I've said all of that to say that I think that ship has sailed for 4.5. We are
> well past feature freeze; and we didn't really have any gating functionality.
> We frankly have very little idea of quality of whats in master right now. It's
> certainly worse than 4.4. So now we'll enter code freeze, we'll try and play
> catch up and fix all of the things we discover that are broken. And invariably,
> we'll be late again.
> 
> If you want to solve this problem; my personal belief is that its really is tied to
> CI. Efforts around Travis are interesting and perhaps are a piece of that
> puzzle. Discussions around running CI are important as well, but I truly
> believe that we need a gating function that prohibits commits that increase
> our level of untested code or code that fails to pass testing. I've seen some
> other projects using pull requests in github, and then using the github pull
> request builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
> 
> [1]
> https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Mime
View raw message