Agreed. Such a map needs to be generated from source, please? -- Lamont Peterson Sr. Systems Administrator | Unix Systems Operations
[cid:image002.jpg@01CEC98D.A33033E0]<http://intermountainhealthcare.org/> From: Paul Robert Marino <prmari...@gmail.com<mailto:prmari...@gmail.com>> Reply-To: "spacewalk-devel@redhat.com<mailto:spacewalk-devel@redhat.com>" <spacewalk-devel@redhat.com<mailto:spacewalk-devel@redhat.com>> Date: Thursday, January 30, 2014 at 9:50 AM To: "spacewalk-devel@redhat.com<mailto:spacewalk-devel@redhat.com>" <spacewalk-devel@redhat.com<mailto:spacewalk-devel@redhat.com>> Subject: Re: [Spacewalk-devel] On quality of patches There is an other factor here that no one has mentioned. Recently I've found and reported a lot of bugs in the nightly repo. Where they came from is usually some one updates a portion of the code to fix a specific issue but since a portion of that code is called by multiple parts of the web interface it may break other pages than the one the developer is focused on. I think we need a map of what these shared file and functions effect so we can do more formal QA testing in the future -- Sent from my HP Pre3 ________________________________ On Jan 30, 2014 7:33, Duncan Mac-Vicar P. <dmacvi...@suse.de<mailto:dmacvi...@suse.de>> wrote: On 30/01/14 11:57, Matej Kollar wrote: > Hi all. > > We welcome community contributions and we want to maintain some level > of quality. Natural expectation is that every proposed patch is > tested for the functionality. I fully agree with you that this is not acceptable. Now, I think your diagnostic is IMHO neither fair or correct. This does not have to do with the "community contributions" but with the setup of the project itself. We sometimes have sent patches that are very strictly reviewed, sometimes needing change multiple times to get a reviewer happy. Then next day our internal testsuite fails only to realize that someone with direct commit access did a big refactoring and committed very broken code in a big patch that was not reviewed by anyone and which quality was also obviously not the best. We asked ourselves, what is the point of reviewing "some of them"?. Not only code but also design decisions and way of approaching solutions. Sometimes this happens with our own patches, depending on the reviewer, they may get committed faster. The setup of the review process is broken. - All code should be committed in similar units (features/branches) - All code should be able to be reviewed and vetoed by everyone OpenStack has this model working quite successfully. Every patch is reviewed with +1, and they need a certain amounts of ACKS to get committed. Everyone can review and people learn in the process, and it is a great source of inspiration for other projects. We care about quality and you can see that we not only contributed our own testsuite in early 2011 with the first release of our own product, but then focused lot of contributions in having the testsuites enabled and working again. But all this is pointless if the process has holes. Right now it depends on a lot of luck to be useful. We suggested not long time ago in the mailing list to move to a github approach where code could be submitted only with pull-requests that need to be reviewed. Policies could be created that at least 2-3 acks is needed to merge a feature. People can study those reviews and learn in the process. Continuous integration could be setup on top of this process, to have up to date results. But what you are seeing, the process is kind of designed to produce those results, which is a process where code has different ways to arrive to master, which different quality outcomes. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com<mailto:Spacewalk-devel@redhat.com> https://www.redhat.com/mailman/listinfo/spacewalk-devel
<<inline: 43D9F316-7150-4FD9-97C0-94E6B1732B1F[96].png>>
_______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
