Hey David! Before you or anyone reads this, I want to say that I support what you’re trying to do here.
I’ve few ideas and concerns so if anyone is skimming please go to the bottom and read the list. On 19-Aug-2014, at 7:15 pm, David Nalley <da...@gnsa.us> wrote: >> >> 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. There is one issue I want to raise -- we’ve about 2 months overlapping between releases and people don’t focus a lot on release branches. The length of a release cycle is perhaps inversely propositional to the interest and efforts around its release. One solution would be to cut down on a 6 month cycle and work on our upgrade process (the db stuff) to have some kind of rolling release way. I’ve some ideas on how to do that and it involves the use of classical shortest path algorithms in the DB upgrader class and remove upgrading mechanism from mgmt server to a tool. (more on this idea soon). Another issue is that companies that are more interested in commercial distributions of ACS may tend not to invest more resources on the upstream, low manpower/resources would mean less attention on ACS releases. Also, sponsored developers/committers are put in conflict of interests by these companies on where to do their work upstream or downstream. Due to overlap between releases, conflicting by their company’s own roadmap for their commercial distro’s release, I think people end up not working on release branches. I don’t want to tell people how do their work — but the right way to work IMO would be to work on the upstream (i.e. ACS) first, and then help with all efforts during releases and take that release for their commercial distribution/fork thereby doing lesser work in the end. I think it’s a solvable leadership issue at those companies. > 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 A possible solution is to have maintainers whose job will be to review contributions in considerate time around these components, like we’ve maintainers in the Linux community. Another challenge on this is having more than one maintainer or component leader. It’s also the culture thing, we’re committer but how many of us are practicing being a committer on day to day basis, reading emails, helping people on JIRA, user ML, reviewing their contributions on reviewboard. Another issue is that most of the sponsored developers who work on the “core” stuff (and not the vendors plugins etc.) are from one company even if we go around manipulating numbers. So, I think we also have a culture issue to solve. > 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. Does it make sense to wait till the 4.4.1 release and either declare code freeze after that or work on these process issues first or in parallel we should do both? > 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 We have few projects using code review on Github using pull requests, we can do those or have gerrit. I was successfully able to implement a pull request based code review workflow in my last startup that worked and got adopted only with time so I’ve few things to contribute on this. Let’s discuss issues around it and try to come up with a solution around it. I’ve few question and challenges to share: - Should we have github pull request or gerrit code reviews or something else? IMO using Github pull-requests will be most fun, implementing/using that would require least effort and just consensus from the community, PMC and infra folks - Timeline or window for accepting a review request? - Having dedicated component specific gurus and maintainers who are there to handling reviews around some ACS piece - Having people submit smaller patches per branch and what to do if someone’s doing major refactoring or framework stuff that would consume both a lot of time and cannot be submitted as small patches? - Some reviewers will be more liberal than others, how do we handle the “ego” issues during reviews? - What if there is no reviewer around a pull request, or people dont’ understand the technology around it and it does not get attention? - CI is one way to validate a change/review/pull-request, do we have enough infra capacity? Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
