On Mon, Apr 23, 2012 at 07:34:14AM -0500, Adam Litke wrote: > On Mon, Apr 23, 2012 at 04:17:18AM -0400, Ayal Baron wrote: > > Hi all, > > > > I would like to discuss the following on today's call: > > > > 1. Gerrit vs. mailing list
Gerrit is an inhibiter for some contributors. One approach to solve this improve gerrit: - Gerrit should send the patch when it notified of a change. This may attract more reviewers. - comments should be posted with their context - pick up a patch/comment from the mailing list Anthony finds the classic mailing list approach more comfortable. Our development model should allow people to: - be able to track current code development - comment without logging in It was suggested to move patch content into vdsm-devel; -patches list is not a common concept. At least as long as -patches is full of machine-generated noise, I think that this should be avoided. Currently -devel is intended to general discussions (though we won't reject a general discussion based on a patch). Another approach is to relax contrinution requirement. This should not be done causually, since if this door is opened it would be harder to shut, and we may be stuck with two competing and mutualy confusing development models. We need to set a checkpoint in time to see if the first approach flied regarding fixin > > 2. mandatory unittest per patch Adam: it's a good idea. adds complexity but leads to a better code. People should be informed on how to add unit tests for their code. Ok then, it's an official policy. We need to add more complex tests, that require a running vdsm instance. > > 3. pep8 Currently we have a whitelist. New code modules should be added to it. Over time all existing modules should be added as well. No objections for this were raised. Cool. > > 4. ?? > > 4. REST API Update / Recommendations Patches are ready for review. There is no objection to separate the code into a different rpm; generating xml/json/collection templates automatically to avoid data duplication may be a little complex at this point (though I would prefer killing the duplication in its infancy). Regards, Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
