Agreed, I was hoping for some comments. Maybe an executive summary would help:
* We would like to have a commit/review mechanism that is much easier for new contributors than the current one * Committers cannot be forced to use it, but the benefits should be so obvious that it's the norm (except for emergencies or security patches) * We propose GitHub as the most familiar and easy to use system * All pull requests should trigger Jenkins to run automated tests, and we shouldn't accept the pull request until they've passed What have I forgotten? And does anyone think we're not on the right track? -- Stephen Turner -----Original Message----- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 29 January 2015 12:25 To: dev Subject: Re: quality improvement project status (fyi != just for your information) no worries, everybody is busy with glibc anyway these days. I didn't have any feedback to our pages, however, That worries me more. On Thu, Jan 29, 2015 at 1:20 PM, Stephen Turner <stephen.tur...@citrix.com> wrote: > Sorry, I was ill yesterday. But I wasn't sure what more we had to discuss > before the hardware arrives. > > -- > Stephen Turner > > > -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 28 January 2015 12:39 > To: dev > Subject: Re: quality improvement project status (fyi != just for your > information) > > I did not see any reactions, are we on for tonight? > > On Sun, Jan 25, 2015 at 12:10 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> H, >> >> This is a question for feedback (fyi == For Your Input;). In the >> meetings we had so far, we created a couple of lists. These are our >> only deliverables to date. In order to know if we are on the right >> track I would like some feedback. >> >> First of all there is the highlevel requirement [1]. It should >> contain everything we want to accomplish in the end. We will revisit >> it next Wednesday and in regular iterations while the project goes >> on. I hope everybody that won't attend next session will have their >> comments sent to us by then. >> >> Then there are two detail pages that we have come up with so far and >> these are not done until there is some form of consensus on them in >> the community. Especially [2] is a page that we should all agree on >> in the end. Right now it is just a working document that we will use >> to implement our own way of working and later propose everybody will. >> It describes what we think are the basics of cloudstack as opposed to >> the extras that people should support on their own and will be >> abandoned if nobody does. >> >> The third page [3] contains a set of requirements that we think will >> make a gate for contributions that is workable for the community. >> >> please have a look and give us your feedback. >> >> [1] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Pr >> o >> cess+Improvement+Initiative [2] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+bas >> i >> c+functionalities [3] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Gate+requireme >> n >> ts >> >> >> (fyi: we are looking to implement a simple contribution workflow >> based on github in combination with jenkins pull request builder for >> now and are still considering what would have to be done to implement >> something like gerrit.) >> >> thanks, >> -- >> Daan > > > > -- > Daan -- Daan
